Re: main difference between expandable and singlepage subfile

Hello Craig,

Am 29.12.2019 um 14:48 schrieb Craig Richards <craig@xxxxxxxxxxxxxxxx>:

The way this is normally handled is to re-present any changed data back to
the user - with a message such as:

"This item has been modified since this screen was loaded - press F5 to
Refresh"

There are two main ways you can recognise that the data has changed:

Yes, but all of these require the user to press a key, so another program loop can actually show the "has changed, press F5" message. AFAIK it cannot be made pop up magically, as long as the *PGM is stuck in EXFMT or READ. :-)

This is somehow related to editing data in a detail-record. From a discussion about annoying record locks which makes other users fail to open a record R/W… To prevent these, one can read the record in question without locking. But then two people may edit the same record. Who is supposed to have the "right" data? The whole topic is inherently complex if you want to do it right.

Of course it would be very nice to have a semi-automatic merge function. If two users edited the same record but different fields, that situation can be resolved comparatively easy. If not, the user should get an overview which fields have been changed by both parties compared to the original, allowing further editing or picking which fields from which edit should be actually written back. To make that easy, it's necessary to create two side-by-side SFLs with changed values and options on both sides to pick appropriate values. Together with two CA/CF "Discard my data" and "Write my data", that would approach the most sophisticated level of support. Of course, there should be screens for confirmation of CA/CF-Choices. And of course, it might be possible to make code "guess" which values would be more appropriate and present a pre-selected SFL to the user, and so on. This easily can be made recursive, because while picking records to actually write back, a third one did edits on that record…

This is less problematic with a (usually) readonly SFL which "just" shows outdated data until reload. One of the reasons, I prefer paged SFLs: The chance that outdated data is shown is less likely and current data is shown with every scroll. Yes, they're more cumbersome and I still haven't come up with a nice idea how to save OPT-selections in a multi-user friendly way to keep them beyond scrolling.

Maybe I'm just too used to graphical applications where it's somewhat more easy to track changes on disk, and update a list view without disturbing the user. A very nice example is Apple Mail on OS X. The list of mails in a certain folder gets updated in nearly real time (if the IMAP server knows how to push changes to the client) when new mails come in or get deleted from another account. This happens without disturbing the already made selection of entries by the user.
This is one of the limitations of the form-based approach of 5250 and 3270, and pure HTML tables without any fancy JavaScript to refresh on the fly. The user always needs to either have a "costly" auto-refresh, or presses F5 for refresh.

https://www.mcpressonline.com/programming/rpg/techtip-use-qualified-data-structures-for-checking-records

Thanks for the hint! Unfortunately, V4R5 doesn't know about qualified DS. :-/

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc