|
program loop can actually show the "has changed, press F5" message. AFAIKYes, but all of these require the user to press a key, so another
EXFMT or READ. :-)it cannot be made pop up magically, as long as the *PGM is stuck in
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 backto
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.