Has anyone come up with a method to generate a temporary value list without adding a TO link?
I have a requirement this morning to generate a value list, unique for each user based on script variables.
Ideally, the easiest way would be to set a global field to the values within the variable and have another field or global field refer to this within ‘Use values from field’. However, a global field cannot be used for values for a value list as it cannot be indexed (and accordingly doesn’t work).
It would be useful if ‘Use Custom Values’ could be set to a global variable, but it can’t (or even use the calculation engine).
I try to avoid adding TOs for minor jobs, but in this case, to restrict the value list to each user while the script is running, I don’t believe I currently have any other option.
To my knowledge, there is no other way than adding a dedicated TO for the type of VL you require. I am using this for multi-lingual applications, displaying a 'DisplayItem' field in that table, with values filled in at application launch (fill for session language, session user-specific values etc.).
It is a shortcoming that 'Custom value list' cannot be calculated.
Yup, us too unless there is cause to move the foremost window around. This value list is in a card window (generic alternative to the standard FileMaker show custom dialog) and my alternative was to create a new table, generate records containing the values that are destined for the value list, view as list and add a button.
However, I was balking at creating an extra TO for the value list, hence creating a new table, fields and TO didn’t make a lot of sense.
If you have a Value List table. You can categorize them and reuse it for most Value Lists in the system. At least you get a little more use out of it. Windows freezing all the windows in place when you open a card window does make this a little more of a pain.
One application I am working on has more than 30 VL TOs (and assorted tables). The main layout is a bit on the heavy side but it loads swiftly over VPN, no complaints
what I do is: a Table named Valuelist with one record, three fields
field one is ID (maybe even useless )
field two is sOne holding only 1 as number for a valid relationship
field three is a global stored textfield holding the values to select from
this table is only bound via field two to my session table.
The session table also only holds one record with only global fields.
The valuelist is established from session table to valuelist table via the constant-one-relationship and uses only the global stored textfield as related value.
First time the valuelist is established FileMaker tells you that the textfield cannot be indexed and the valuelist will not work ... but it does all the same
now this valuelist works in every context in the recent file and is dynamically filled via trigger.
On-enter gets values for the field needing the valuelist either from SQL requests or from related records or...
The validate trigger processes the selected value - getting IDs etc. - and empties the valuelist
This technique let me downsize my relationship graph by at least 30%, so many TOs for valuelist I don't need anymore...
That is essentially what @harvest is describing above. MagicValueList is cool. I've found it easier just to use a card window and a table with a found set. If I need to, a virtual list in a popover.
This is very good. I must admit, I’d have probably followed this with the exception that FileMaker Pop Up Menus are so poor within Windows, mostly I’ve gone a similar route to Josh using card windows and methods to display list views in these, with type ahead search fields at the top.
You set $$DYNAMICVALUELIST in the OnObjectEnter trigger of the field you want to use that value list and it's done.
Also, this technique plays nicely with storing ValueLists as data too. Data can be retrieved either by relationship (my preference) or via ExecuteSQL()
That said I use the technique described in dialogs and having 9-12 cardwindows popping up in a dialog might feel a bit alien to the user.
And yes, type ahead is another one I use in cases with a wide range of records to select from, e.g. select the customer for a new project in ERP systems where the context for preselection couldn't be narrowed beforehand.
It is frustrating being limited to not using the full functionality available,, but we now take a view (voiced by Matt Petrowsky in a podcast) that certain, well established and frequently used features are there for backward capability and not necessarily appropriate for current, WAN based use.
At the risk of repeating myself from previous posts, we pretty much view calculation fields, pop up menus, locally stored container fields, and recently even summary fields within this legacy category (possibly a great topic for another thread ). Hence we’re rapidly adjusting our mind set from ‘having to do yet another work around as this feature nearly works for this purpose, but not quite’ to ‘having to do things this way for the purpose needed (or for performance).
We don’t really worry about whether the interface is alien to a FileMaker user, as we rarely work for a seasoned FileMaker user. FileMaker is just our platform to develop our apps and this is all our users know. Our systems are rarely referred to as FileMaker, it is either our SaleFaith brand name or generic descriptions such as ‘the CRM system’.
It sounds like we’re all taking varying degrees of a similar approach.
what I wanted to state is I rarely let users do any direct interfacing but try to go via dialogs/wizards... and in a dialog already open in front of the main window another series of cardwindows popping up under/left/right whereever would in my opinion be disturbing for the experience of/with the application
). Hence we’re rapidly adjusting our mind set from ‘having to do yet another work around as this feature nearly works for this purpose, but not quite’ to ‘having to do things this way for the purpose needed (or for performance).