Back to Four Js Website
Four Js Customer Forum
Subscribe for automatic updates:
RSS
Sign in for full access
|
Help
Four Js Development Tools Forum
>
Discussions by product
>
Genero BDL
>
DISPLAY TO issue
Most recent posts
Pages: [
1
]
« previous
next »
Reply
|
Print
Author
Topic: DISPLAY TO issue (Read 41197 times)
Sundar K.
Posts: 17
DISPLAY TO issue
«
on:
June 19, 2009, 07:38:55 pm »
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.
nacsz4.tgz
(3.45 KB - downloaded 1014 times.)
.
Posts: 64
Re: DISPLAY TO issue
«
Reply #1 on:
June 20, 2009, 01:14:41 pm »
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
.
Posts: 64
Re: DISPLAY TO issue
«
Reply #2 on:
June 20, 2009, 01:25:27 pm »
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.
Posts: 1119
Re: DISPLAY TO issue
«
Reply #3 on:
June 22, 2009, 12:33:00 am »
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
Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of
https://4js.com/ask-reuben
Contributor to
https://github.com/FourjsGenero
Reuben B.
Posts: 1119
Re: DISPLAY TO issue
«
Reply #4 on:
June 22, 2009, 03:36:20 am »
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.
Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of
https://4js.com/ask-reuben
Contributor to
https://github.com/FourjsGenero
Sundar K.
Posts: 17
Re: DISPLAY TO issue
«
Reply #5 on:
July 02, 2009, 04:49:31 pm »
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.
.
Posts: 64
Re: DISPLAY TO issue
«
Reply #6 on:
July 02, 2009, 06:33:27 pm »
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
nacsz.4gl
(1.74 KB - downloaded 1032 times.)
Reuben B.
Posts: 1119
Re: DISPLAY TO issue
«
Reply #7 on:
July 07, 2009, 08:47:36 am »
Quote from: Thomas Smith on July 02, 2009, 04:49:31 pm
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.
Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of
https://4js.com/ask-reuben
Contributor to
https://github.com/FourjsGenero
Leo S.
Posts: 129
Re: DISPLAY TO issue
«
Reply #8 on:
July 07, 2009, 02:29:21 pm »
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.
Posts: 545
Re: DISPLAY TO issue
«
Reply #9 on:
July 07, 2009, 02:57:17 pm »
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.
Posts: 129
Re: DISPLAY TO issue
«
Reply #10 on:
July 07, 2009, 03:41:18 pm »
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.
Posts: 129
Re: DISPLAY TO issue
«
Reply #11 on:
July 10, 2009, 08:18:42 pm »
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
Pages: [
1
]
Reply
|
Print
« previous
next »
Jump to:
Please select a destination:
-----------------------------
General
-----------------------------
=> General Discussion
=> Ask Reuben
=> WWDC21
-----------------------------
Discussions by product
-----------------------------
=> Products announcements
=> Genero BDL
=> GWS
=> GAS and GBC
=> GDC
=> Genero Mobile for Android or iOS
=> Genero Studio
=> Reporting tools (GRW, GRE)
-----------------------------
Jobs
-----------------------------
=> Jobs
Powered by SMF 1.1.21
|
SMF © 2015, Simple Machines
Loading...