If the table is in read only mode you can use any form you want and the
user can't edit the data.
I'd just put the table in read only and use DIALOG with the input form.

On Wed, Feb 6, 2019 at 1:32 PM Jim Crate via 4D_Tech <4d_tech@lists.4d.com>

> Is there a convenient way to mimic the ease of DISPLAY SELECTION / MODIFY
> SELECTION to allow read/only or read/write access when using a listbox? Is
> DIALOG the only option?

Yep but call it 'best' option.

You didn't say which version of 4D we're talking about but it sounds like
an old one so I'm going to assume you're working in v15 at least. If it's
earlier than that it's probably not worth the effort to re-work it. You
know, you _could_ drop a Tesla drive train into an '92 Impala with a lot of
work and money. Or you could fix your '92 Impala with parts from another
'92 Impala. Chip is right about using variables. I did that in v13. It's
tedious, takes pages of code and is hard to change. Put the effort into
convincing the client to upgrade. So-

Make a form and display it using DIALOG in a new process. The form contains
a listbox. In v15 it could be named selection based or array based. Doesn't
really matter - just avoid selection based. Why? Because the idea is to
have a persistent list of records selected by the user. The actual
selection may change based on what the user does in the detail form. In v17
it could be an entity selection instead.

Feel free to add a quick search box above the listbox for the user to find
records quickly on a small set (like 1) criteria with the option for a more
involved query.
Depending on the type of data this list can be pretty concise or it may be
larger. If the records are fairly concise think about having the input form
right there on the dialog. This could be a subform or you could add the
fields directly. The user clicks on a record in the list and you load the
record. I like to include a button that toggles between READ ONLY and READ
WRITE. Default to read only. The uses can click around the list and records
pop up. If they need to edit something toggle the record to READ WRITE.

The advantage of a subform is you can easily swap the table you're looking
at (the listbox doesn't really care) and simply set a different subform to
the subform object.

If this is a converted database check the compatibility settings regarding
displaying fields in dialogs. For newer versions this already baked in.

Alternatively you could also pop the user selected record into a new
process for editing. This makes it easy to let the user open multiple
records from the same table in multiple windows.

OK, this crazy talk - you want to go old school: show a list and double
click to open the input form.
Fine, take all that input stuff off the dialog and add some more fields to
it. For the On double click event you toggle the table into READ WRITE,
load the record and then display it in the input form using DIALOG again.
There's nothing wrong with Modify record but DIALOG is more flexible
precisely because it's ambivalent to read write state. If the record is
locked the user can't change anything.

I've been using this approach in v15 databases for years now and it
generalizes easily to v17+. In fact it's really much easier to implement in
v17 than the old school Modify Selection approach, in my opinion.

I realize I've thrown out a lot of options here. The thing is they are all
based on a fairly small set of principles and techniques. That's what's so
cool - you have all that flexibility from using DIALOG, a listbox and some

Kirk Brooks
San Francisco, CA

What can be said, can be said clearly,
and what you can’t say, you should shut up about

*Wittgenstein and the Computer *
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to