Making Dynamic a Picker Script Set

[natursalus]

Hello,

In my current project I am using some pop-up menus that get their values from lenthy value lists (> 100).

Since I am no expert neither on programming nor on FM, I was able to set up a simple "picker" based on "PopupSelectNew2.fp7" downaded from this website sometime ago and authored I think by bcooney (not sure).

Since I have to use more than once the "picker· concept throughout my project, I wonder if it is feasible and worth it to modify the picker script set of the aforementioned sample so that it can be "dynamic" (not sure this is the right jargon) and usable with different tables in different parts on the same project.

Finally if the answer is yes, guidance on how to achieve it is requested.

Thanks

[bcooney]

Yes, I uploaded the demo, but the technique is common. The term that you are looking for is "modular." This describes writing a routine that is context-independent. One would use script parameters and conditional scripting to accomplish this.

However, I don't think it'll be worth it to attempt to make the popup select modular. I think you'd end up with so much abstraction that it would be difficult to troubleshoot.

[natursalus]

Hello bcooney,

Thanks for your useful demo and for the term "modular".

Then, if you were confronted with a situation similar to mine: at least 3 fields that choose values from lengthy drop-down lists and/or popup menu, what would be your approach?

In my case, all I can do is to repeat your picker script set every time that I need to choose values from a lengthy drop-down list or popup menu?

Thanks

[bcooney]

If you're on the same layout, it suggests that a conditional value list is possible.

[natursalus]

Yes I am on the same layout, but in my case a Conditional Value List cannot be setup because it doesn't make much sense.

Just to give you one example:

BloodType --< BloodTypeFood >--- Food

For instance, the BloodType table has the following fields.

__kpBloodType ID

BlodType (A, B, AB, O)

SecretorStatus (Boolean)

FoodName

To choose the values for the FoodName field I have superimposed two fields:

the bottom hidden field is BloodTypeFood::_kfFoodID associated to the FoodName Dropdown list (Food::__kpFoodID & Food::FoodName)

the top field is Food::FoodName

So in this case values for the BloodType::FoodName are directly obtained from the Food table. And there are no rational criteria that could be used to "organized" and "reduce" the size of the FoodName list which is around 500.

In other parts of my project I have sorted out the same problem using your picker script set because a Conditional Value List is not possible.

As I understand it the "picker" concept is needed when the value list is lengthy and it can't be reduced by for example Conditional Value List. But, what happers when the picker concept has to be used several times on the same project? All that is left is use it as many times as needed?

Thanks

[comment]

what happers when the picker concept has to be used several times on the same project?

It's a simple matter of efficiency; in order to make a picker reusable, you must parametrize:

• the layout to go to;

• the field from which to pick the value;

• the field to set to the picked value.

It's very easy to duplicate the script and change those parameters. It's not as easy to send three values via a single script parameter - esp. if you want those values to be impervious to field/layout being renamed. So all you gain here is a more complex script and more work to adapt it to another context.

[natursalus]

Hello Comment,

Okay, I got it!

Thanks

[bcooney]

Yes I am on the same layout, but in my case a Conditional Value List cannot be setup because it doesn't make much sense.

Just to give you one example:

BloodType --< BloodTypeFood >--- Food

For instance, the BloodType table has the following fields.

__kpBloodType ID

BlodType (A, B, AB, O)

SecretorStatus (Boolean)

FoodName

FoodName should not be a field in the BloodType table.

To choose the values for the FoodName field I have superimposed two fields:

the bottom hidden field is BloodTypeFood::_kfFoodID associated to the FoodName Dropdown list (Food::__kpFoodID & Food::FoodName)

the top field is Food::FoodName

If you are on a layout based on BloodType table, then placing a field from the BloodTypeFood table will only show you the first related record from that table (provided there is a relationship from BloodType to BloodTypeFood by BloodTypeID. Otherwise, records from BloodtypeFood should be in a portal.

I think that your best data entry approach would be to populate the BloodTypeFood join table from a portal on a form view of Food, since the choices of BloodTypeID and SecretorStatus are small.

[natursalus]

Hello bcooney,

Thank you for you comments.

I just showed you a liitle piece of my project structure. As a matter of fact this piece is a sort of "add on" to my structure aand was suggested by comment (http://fmforums.com/forum/topic/79836-multiple-and-find-script/) to sort out some problems that I had with one of my reports.

My whole point was to find out whether your picker script set could be made modular. Since that is not a good idea, I will just recreate your picker script set as many times as necessary in my project.

Although this is an out of the topic question I would like to ask you the following question. Once I have selected the desired value from the CON_select layout I get back to my original layout, but when that happens the window size is smaller than optimal (most of my layout objects / fields are out of sight). In which part of your picker script set should I add a line to make the window size larger?

Your picker script set turned out to be the most managable, out of all that I have found so far, for a nonprogrammer and FM newcomer like myself. Sometimes simple and workable FM samples are valuable "flash lights"

Thanks

[dansmith65]

Personally, I love creating modular features in FileMaker. A record picker is among the features I have created. Although, it can be rather complex to implement this feature, and I don't think i'll get around to creating a sample file any time soon.

To give you the basic structure I use...

1. To pass multiple parameters via a single script parameter, I use dictionary custom functions which can be found here: http://sixfriedrice....ripts-advanced/
   
2. I create a separate script for each type of record that needs to be selected (selecting Customers is done in a different script than selecting Orders)
   
3. I also create a separate "calling" script for each layout based on a different table occurrence, which needs to select records. This script calls the picker script, then uses the script result to set a field.
   
4. To pick a record, I open a new window and pause the script; requiring the user to click a button on the layout to either accept the selection, or cancel.
   
5. I use this technique to manage the selection of records: http://fmforums.com/...n-example-file/
   

[natursalus]

Hello dansmith65,

Many thanks for your suggestions I am going to copy and keep them in a safe place. Whenever I develop the necessary scripting skills your directions will be handy.

[bcooney]

Um, Dan, have you looked at the demo file?

[comment]

I create a separate script for each type of record

...

I also create a separate "calling" script for each layout

So what's the point? Instead of 2 scripts, you have 3 or 4.

BTW, I have noticed there is no link in this thread to Barbara's demo:

http://fmforums.com/...257#entry349257

[bcooney]

Ah, so that's why Dan didn't realize that the demo does pretty much what he describes. I'll take this opportunity to again point out that this is a public domain technique and not original work on my part.

[dansmith65]

Sorry, I should have gone looking for the mentioned demo file before I posted in this thread. I didn't understand what was being asked.

Yes, what I mentioned is pretty much how the example file already works.