Hi,

I am creating a database using version 8 Advanced for a windows domain
(Pro / Server). I have no experience in version 8 (I've been using
version 5.5).

Some delegated users will have rights to add values to value lists.
All FM menu item will be eliminated. All navigation will be guided.
More or less like in kiosk mode.

What is the best method for implementing access and editing of value
list without really going into the value list dialog box?

So far as I know, there are two methods:

1.- A field contains a list of values separated by carriage returns.
The target field could be formatted to show values from this value
list field. Then, delegated users could have access to the value list
field through and administration layout, and edit the values of the
field there.

2.- FM value lists and editing value list dialog box.

I would not like to use FM value list and direct value list dialog
box, because of security and interface access reasons.

Is there any other alternative in version 8, or any variations on the
above mentioned?

Regards,

TIA

Carlos,

You are in for a pleasant surprise with FileMaker 8.

Value lists may be created based on entries in a table. This table may have
any sort of controls you like as far as ability to add/edit/delete items
from the value list. You not longer have to go into a dialog box to update
those values.

Bill

"Carlos Pereira" <cpereira (AT) nnnhotmail (DOT) com> wrote

In article <iaqdneul9fzX8cvenZ2dnUVZ_sidnZ2d (AT) comcast (DOT) com>, wjm (AT) wjm (DOT) org
says...
Actually you've been able to do that since filemaker 5, maybe even even
3. (8 does expand on what you can do, but we've had a simple 'value list
derived from a table' for a long time now.

In article <m9mcl1ppdcnn6134m9q0c9p1cea42oto8o (AT) 4ax (DOT) com>, Carlos Pereira
<cpereira (AT) nnnhotmail (DOT) com> wrote:

Also in FileMaker 5.5

3.- The value list can be collated from data in a field in the records
of a related database file / table.

This is particularly useful when you want the value list to display
only relevant values based on the data in another field (eg. only the
Sub-categories for the already chosen Main Category).


If you really want PROPER editing of value lists you need to use option
3 and create your own pile of scripts so that, for two examples:

- when someone fixes a spelling mistake in a value all the
records already using that value can be updated.

- when a value is deleted, do the records using that value
also get deleted, or the value changed to something else,
or left as-is for historical data.

If you delete / edit an existing value from a value list that is being
used for a field formatted as pop-up menus, checkboxes, etc., then you
can no longer access the original when performing finds (at least not
manually, you still can via a script or a second copy of the field
that's formatted to allow normal typing).


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Thank you all for your valuable replies.

I have investigated into the mentioned options. I have created a
"Value list" file. Inside this file, a value list field. Then, use
this field to hold one value of my value list for each record.
Finally, display this records both:

- in a Preferences file (formatted as a portal, for administrative
purposes)
- in a field in the User file (formatted as a drop-down list or
whatever).

This is fine, as Helpful Harry mentions, it would require scripts to
update the records that are displaying the value from the value list,
if this value its modified or deleted by the administrator. I guess
this can get very complicated. I was wondering if FM8 finally made it
easier. It seems the answer is NO.


This is potentially dangerous. Have you found out any way around the
issue, maybe though the use of a special technique?

Regards.

In article <6obfl199tt9kpcc9es2kvvsnp7mmh9kef7 (AT) 4ax (DOT) com>, Carlos Pereira
<carlosp- (AT) nnhotmail (DOT) com> wrote:

It does get complicated to handle the modifying of Value List entries.

If you're wanting to keep historical values and still be able to Find
them via the field's pop-up menu / checkbox / etc. then you have to
keep all the values and not allow them to be deleted. Obviously this
gets cumbersome if there are eventually LOTS of values. One way around
this would be to have a two relationships to the Value List file - one
for "current" values and one for "all" values. You could then either
have two versions of the field on-screen or do some playing with
layouts, buttons and a Find button to display the appropriate value
list when in Find mode.


If you are not wanting to keep historical values, then it becomes a
little easier (in some ways).

For the deletion of values you can use a relationship back from the
ValueList file to the MainFile where the option to delete the related
records turned on. This means that when a value is deleted, so are all
the records using that value. (Obviously some sort of "Are you really
sure" warning needs to be displayed.)

Editing of values gets a little messy. The way I've done it in a couple
of database is:

- Have an "OriginalValue" field in the ValueList file. This is
an auto-enter by calculation field:
= If (IsEmpty(ValueField), "", ValueField)

When the ValueList file record is created the OriginalValue
field will be given a copy of the same text. This gives you
a basis for another relationship from the ValueList file
back to the MainFile even when the ValueField has been
changed.

- Then a "Fix Related Records" button can be used to run a
script that loops through a portal using the OriginalValue
relationship to change the related records' fields to the
new ValueField text, and then OriginalValue is set to
ValueField ready for any later editing.
eg. Something like:
Loop
Go To Portal Row [First]
Set Field [MainFile_OldValues::Field, ValueField]
Exit Loop [Count(MainFile_OldValues::Field = 0]
End Loop
Set Field [OriginalValue, ValueField]


For the button my databases actually use a Calculation field with a
container result. The calculation is:

If (ValueField = OriginalValue, "", g_FixButton)

so that the "Fix" button is only displayed when the ValueField data has
been altered (ie. is different from OriginalValue), otherwise it's
"invisible".



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Hi Helpful Harry,

Thank you very much for your message explaining techniques for
handling updates in managed value lists. I am putting it into practice
right now, tweaking it to my particular needs. It has been very useful
and easy to understand, thanks to your detailed explanation.

Regards,

Carlos