next »

[Sundar K.]

Linux: RHES-4 (2.6) GLibc (2.3)
Windows GDC version 2.11.05  Genero BDL: 2.11.05

The DISPLAY TO code behaves incorrectly when dealing with arrays.  If you fill an array with data and do something in a loop like:
 DISPLAY p_detail.* TO s_detail.*, then resizing vertically doesn't show the lower rows being exposed.  The attached file contains a demonstration. Follow the comments in the INSTRUCTION file.

[.]

I can't open the attachment as using phone but I assume in the example you are actually doing:

DISPLAY ARRAY p_detail TO s_detail.*

sorry if you are indeed doing this in your example but obviously it wouldn't work otherwise

[.]

Sorry, read post correctly now. I always thought that if you display to individual screen record elements then it's upto you to maintain everything.

I would (without having seen the test case) either use a Display array in a multiple dialog or do a display array and in the before row do an exit display (can't remember if you need a before display to set the current row or not)

hope this helps and if not will check on Monday your test case to see what you are trying to achieve.

[Reuben B.]

Jeff,

the ...
DISPLAY ARRAY arr TO scr.*
   BEFORE DISPLAY
      EXIT DISPLAY
END DISPLAY

... technique you hint at suffers from the same issue as the DISPLAY TO Thomas is using.

When the form is re-sized, the DISPLAY ARRAY is not active, and hence no communication takes place between the front-end and the back-end saying please send the information for the extra rows that are now being displayed.


Thomas,

What will work for now is something like ...

         DEFINE p_detail DYNAMIC ARRAY OF RECORD
                cname char(16),
                caddress char(16),
                ccity char(16),
                cstate char(2),
                czip char(5)
                END RECORD

...

       DISPLAY ARRAY p_detail TO s_detail.* ATTRIBUTES(UNBUFFERED, ACCEPT = FALSE, CANCEL=FALSE)
            ON ACTION ac_ring_find
               CALL initRec()
             
            ON ACTION ac_ring_exit
               EXIT DISPLAY
        END DISPLAY

... which ensures that the array is active so that any form resizing results in the communication taking place to send the extra rows from the back-end to the front-end.

Reuben

[Reuben B.]

I should also point out the WANTFIXEDPAGESIZE attribute as in

TABLE (WANTFIXEDPAGESIZE)

Making the above change to your .per will mean that only X number of rows will only ever be visible so you only have to populate those rows with the DISPLAY TO statement and not worry about the user resizing the form and making more rows visible.

[Sundar K.]

The responses contributed are greatly appreciated.

However, think of a user looking through header records (Next/Previous) trying to locate a particular detail record.  If the user stretches the screen vertically, the user will improperly assume that the desired detail record simple does not exist.  This is 'deceptive' behavior by the application.

Using multi-dialog might work if with each Next/Previous would pop the user in and out of the DISPLAY ARRAY.  Using DISPLAY ARRAY will not work for us because our product's architecture is modular and uses 'CALLs' to go into DISPLAY ARRAY, INPUT, INPUT ARRAY, and CONSTRUCT statements.

Also, when you execute the the attached application, you will see that the application works properly once the screen is vertically stretched the first time.  Sounds like a bug.

[.]

Not quite sure if I follow how you go into/out of display arrays.

Certainly with your example it would work to simply wrap the DISPLAY ARRAY in a DIALOG statement, unbuffered, with dynamic array's (so you don't have to specify the count).

I've reworked (roughly) the .4gl you sent with something that I think is what you are after.

My normal route (if you're doing similar to what I think you're doing) would be:

DIALOG ATTRIBUTE (UNBUFFERED)

    INPUT lr_input.* FROM s_input.*
    END INPUT

    DISPLAY ARRAY p_detail TO s_detail.*
    END DISPLAY

    ON ACTION exit
        EXIT DIALOG

    ON ACTION next
        -- Because the DIALOG is unbuffered the handling of the newly read record and array
        -- will be done by Genero
        CALL read_next_record() RETURNING lr_input.*
        -- Of course, I could always have just issued an EXIT DIALOG and done it all elsewhere


    ON ACTION previous
        CALL read_previous_record() RETURNING lr_input.*

END DIALOG
..
..
FUNCTION read_next_record()
    DEFINE lr_detail     RECORD LIKE detail.*
    DEFINE lv_row       SMALLINT

    FETCH c_next_header INTO lr_input.*

    CALL p_detail.clear()
    FOREACH c_detail USING lr_input.key
           INTO lr_detail.*

        CALL p_detail.appendElement()
        LET lv_row = p_detail.getLength()
        LET p_detail[lv_row].* = lr_detail.*
    END FOREACH

END FUNCTION

[Reuben B.]

The responses contributed are greatly appreciated.

However, think of a user looking through header records (Next/Previous) trying to locate a particular detail record.  If the user stretches the screen vertically, the user will improperly assume that the desired detail record simple does not exist.  This is 'deceptive' behavior by the application.

Using multi-dialog might work if with each Next/Previous would pop the user in and out of the DISPLAY ARRAY.  Using DISPLAY ARRAY will not work for us because our product's architecture is modular and uses 'CALLs' to go into DISPLAY ARRAY, INPUT, INPUT ARRAY, and CONSTRUCT statements.

Also, when you execute the the attached application, you will see that the application works properly once the screen is vertically stretched the first time.  Sounds like a bug.

Hi Thomas,

Looking at my genero mailing list archive I reported the same issue in 2004 and 2005 when I was a user so I can sympathise and agree you end up in a situation where what is displayed on the screen can be interpreted as saying there are only X records in the array when in fact there is more records

However in terms of the Genero architecture, the bare minimum number of rows are sent from the back end to the front end in order to display the array.  If you have populated the array in file_A.4gl but the current active dialog is in file_B.4gl, then when you stretch the array what you are after would require the runner to get the additional data from file_A.4gl.  This is emphasised even more if the array was initially displayed with an ON FILL BUFFER.    When the program is in file_B.4gl, if the window is stretched we wouldn't expect the program to go back to file_A.4gl and execute the ON FILL BUFFER of a non-active DISPLAY ARRAY.  It maybe that to get what you want, we ought to send more than the bare minimum number of rows, but then the question will be, how many more rows?, the maximum that can be displayed on the screen?

I am pretty certain WANTFIXEDPAGESIZE prevents the situation occuring, at the cost then when the table is stretched the table size doesn't grow.  Certainly using DIALOG so that the array is active when the window is resized means that the rows will be populated.

One of the things that has often been talked about is the abilty to re-use a sub-dialog inside a DIALOG.  With your products modular architecture, that maybe the better long term solution. 

[Leo S.]

Hi folks, we discussed internally quite a for long time that it is possible for a simple
DISPLAY ARRAY
without any multi dialog extension to live in the GUI even after the dialog has been finished.
This would however only work for arrays with modular scope, creating an array with FUNCTION scope and leaving that function forces the VM of course to disable the interaction in the GUI.
But if the array scope is module there speaks nothing against  letting the visible representation of the array alive, that means you can scroll inside and you don't get wrong values if the window is resized (e.g. made bigger...)
May be even arr_curr() could be asked for if the following instruction is a MENU or INPUT !

The syntax could be a simple flag like
DISPLAY ARRAY ... ATTRIBUTES(KEEPALIVE)

and magically all your DISPLAY ARRAY's with the
DISPLAY ARRAY
   BEFORE DISPLAY
      EXIT DISPLAY
END DISPLAY
technique don't need WANTFIXEDPAGESIZE anymore.

If you find this useful please raise your hands and I will add it to the list of feature requests
Kind Regards, Leo

[Sebastien F.]

Leo,

I believe we should clearly specify this before asking for votes...
While your idea sounds good, I would mention all limitations this KEEPALIVE option would bring...
Since the DISPLAY ARRAY dialog would be gone, actually no navigation would be possible... (moving in the list)... right?
Is this really the expect behavior?
Does it make sens to show only a sub-set of a record list? What if you have 100 rows to show?
Will programmers have to handle navigation themselves?
Will the GUI table look like active, inactive? It should look inactive, and not get the focus I think...
Will end users understand that the have a kind of phantom list?

From a syntax/semantic point of view, since this is not a real interactive dialog, should we not define a bright new instruction such as:

SHOW ARRAY arr TO sr.*

?

Anyway I believe every developer should first ask the end users what they are expecting from their applications.
If they want a real scrollable list, then the only choice is to have are real controller/dialog behind, using multiple dialogs.

Maybe one could re-use / bind existing singular dialogs into a DIALOG / END DIALOG block, with something like:

  DIALOG
        EXTERNAL DIALOG function-name   -- calls a function that defines a singular dialog.
        INPUT BY NAME  ...    -- local specific sub-dialog
        INPUT ARRAY ...  -- local specific sub-dialog
  END DIALOG

And I believe another option could be to have the so called "concurrent dialogs", where several singular DISPLAY ARRAY / INPUT ARRAY / INPUT / CONSTRUCT can run in parallel...

Seb

[Leo S.]

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

[Leo S.]

Hi Thomas, to come back to your initial problem:
The VM cuts the DISPLAY TO's to the actual table size (4 in the sample+ one buffer row) and does not memorize the rest (of your 8 rows in the sample) somewhere.
The proposed featured solution with the 'KEEPALIVE' flag for a DISPLAY ARRAY left in BEFORE DISPLAY would require from you to hold a module local array with the fetched details. This would ensure that the VM can sync the array with the table at a later stage even if the end user resizes the table at the client side to a much bigger extend.
Would that be ok for you ?
Kind Regards, Leo