Hi Seb, before Genero and BDL(WTK) the DISPLAY ARRAY was what the name implied :it displayed the array.
But even after the Array was displayed it was visible on the screen and people usually did the DISPLAY TO thing to refresh the data from a MENU or INPUT instruction . Now we introduced our nice resizable windows and the people run into the trap that they have to add the WANTFIXEDPAGESIZE attribute to keep their code running at the cost that the result looks a bit clumsy when it comes to resizing.
I'd define the goal for this little extra flag to keep changes in the sources at a minimum and to get better GUI behavior.
So of course navigation in the array should be possible. You can click inside the array, use cursor/PageUp/PageDown keys, scroll...its
just that the VM still syncs the array content with the client. The DISPLAY ARRAY does not receive any events because the scope of the DISPLAY ARRAY has been already left.
Suppose the next statement is a MENU instruction, then pressing whatever function key is part of the MENU statement.
If you are in an INPUT and jump to the display array with the mouse, an AFTER FIELD is triggered , but again, hotkeys bound to ACTIONs belong to the INPUT.
>Does it make sens to show only a sub-set of a record list? What if you have 100 rows to show?
If the array has 100 rows you can scroll thru 100 rows
>Will programmers have to handle navigation themselves?
No,it works like being in a normal DISPLAY ARRAY
>Will the GUI table look like active, inactive? It should look inactive, and not get the focus I think...
It looks active and it can get the focus
>Will end users understand that the have a kind of phantom list?
End users will see a scrollable list and appreciate that they do not have a strange inactive list which does not resize properly and looks a bit active(because of its active background) but with inactive scrollbar:-)
>bright new instruction SHOW ARRAY arr TO sr.*
Yes, sounds also good.
My other suggestion would be to smuggle this magic KEEPALIVE flag either in the .per or into a fglprofile option so that
*all* DISPLAY ARRAY's with this 'just show the array' pattern could make use of the new post-dead interaction flag , the compiler can potentially detect the
DISPLAY ARRAY BEFORE DISPLAY EXIT DISPLAY END DISPLAY thing.
This would ease the migration of existing code a lot IMHO.
Of course, if you write new code ,multi dialog code helps and in a not specified future the concurrent dialogs will appear but we think this small feature solves exactly the problem the people have currently when coming from I4GL/BDL and its still there as we have read it here.
Kind Regards, Leo