Goto Layout after selecting value in pop-up list

[db_tragic]

Firstly

Database includes the following tables:

HorseOwner, Horse, TreatmentNotes

 

Have set up a 'start' screen as a starting point for users.

 

They have the choice to search by Owner Surname, Horse Name or Invoice To fields.

 

I've set up value lists for each of these, which the user can choose from a drop down list.

 

Firstly,

Once they select the appropriate record from the pop-up, what's the best way to take them to the related record?

 

Secondly,

I considered an alternative for the Owner Surname value list so it included the Location value as well (in case there were more than one instance of a given surname (different individuals) thus identifiable by the location value appearing next to the surname).

 

Will the solution for the first option still work for the second option (given the displayed popup also shows a value from a second field?)

 

 

[LaRetta]

The best way to 'take them to the related record' is by performing a find (see my prior response). It takes less resources than GTRR (Go To Related Record) . You can provide global text and User can enter either surname or horse or location then script would search both fields as 'set global with value then add new record request then set horse name with global value.'

You said surnames can reach 200-300 and pop-up isn't the right tool for it. And since one owner can have many horses, the Horses list would be longer. I suggest global text for them to type part of the name or horse then let the number of results dictate where the User goes to display the results. :-)

If you are SURE the number of records will stay small (such as Location?) then you can use global text with pop-up attached and OnObjectModify script trigger but ... that just fires the script. You still need to write a find script. :-)

[db_tragic]

 Ok.....looks like I need to start learning about 'global text'. Seems to keep coming up more and more!

 

Thanks again for your input. Any good reading resources that explains this in any sort of detail?

[LaRetta]

If you would like a small demo file then I or someone here could provide one. Unfortunately I won't be back at a regular computer until this evening. Let me know if it would help you.

Really, all you do is create a regular text field in Manage Database. Select options and go into storage and click 'global'. Then write script using the global but I would be happy to still give you a file. It sounds like you would benefit by stepping back from design and reading the Help at least once through first. :-)

[db_tragic]

Hi LaRetta, I'll get onto some reading on globals as suggested. A demo file might be useful, but no hurry - I only have time to work on this in bits n pieces as it is. Really appreciate your input. Thankyou. Re the goto record after selecting a popup value - I had a go anyway for the sake of the learning experience and got a script trigger working fine(Set variable/Go to Layout/Set field), but only for the Horse Owner field. When I applied the same process to the Horse Name field, the correct layout (Horse Details) would open, but would only populate the Horse Name field, and none of the other fields.

 

The relationship between Owner & Horse is though a primary key (not the animal's name), so I am guessing that Filemaker doesn't know what Owner details/or Horse record the selected horse is connected to. I used the animal name as the variable in the script, but think I need to somehow include the primary key to join the relationship - just not sure how to script it.

 

I can see there would be a problem if there were more than one horse with a given name. Is this where you tell me to go and read up on globals again!

Below is the script I did try(which didn't work);

Set Variable [$animal; Value:Animal Details::Animal_FN]

Go To Layout ["Animal Details" (Animal Details)]

Set Field [Animal Details::Animal_FN; $animal]

[LaRetta]

Since I did not know how you were related nor which table Location was in, I've put together a very generic sample (attached) of performing a find in version 12.

 

It uses a global text field in the Preferences table to hold the User selection (one of the values of global fields, also that it can be accessed from anywhere without a relationship).  Find script takes that value and performs the search.  My use of IDs and structure are standard relational.  If there is possibility that one horse can have many owners then you need a join table between them but since you are so new, I decided against going there.

 

There are many configurations but a simple basic find is most important to learn.

 

As for the script you reference above of:

 

Set Variable [$animal; Value:Animal Details::Animal_FN]

Go To Layout ["Animal Details" (Animal Details)]

Set Field [Animal Details::Animal_FN; $animal]

 

Well, you are setting $animal with the FN ID from Animal Details.  Then you go to a layout based upon Animal Details and then you set a field in Animal Details with $animal.  You are setting the same record with the same value.

 

In FileMaker, perspective is everything.  Where are you standing (what is the table occurrence of the layout you are on)?  Look in Layouts > Layout Setup > 'show records from' pop-up.  Then look in graph to see your relatives.  :^)

Horses.zip

[db_tragic]

You're a legend LaRetta! Thankyou for the sample file.

 

As I look through how you've set it up, and how the script relates to the global field, I can see how the global field serves it's purpose. 

 

A couple of questions come to mind from what this shows me:

1. If other searches are set up within a file, from other layouts (e.g. say an invoice date), would I reference the same global field, or set up another table with it's own global field ( in either case, with a different script of course)? i.e. Where using a scripted global field is preferred for a find, can the one global field be used for any other similar search elsewhere in the database (generally speaking)? Say for example, if on the same startup screen, I wanted the user to be able to do an invoice search based on an entered date, could I reference the same global field (but with a different script)?

[LaRetta]

1. If other searches are set up within a file, from other layouts (e.g. say an invoice date), would I reference the same global field, or set up another table with it's own global field ( in either case, with a different script of course)? i.e. Where using a scripted global field is preferred for a find, can the one global field be used for any other similar search elsewhere in the database (generally speaking)? Say for example, if on the same startup screen, I wanted the user to be able to do an invoice search based on an entered date, could I reference the same global field (but with a different script)?

 

Great question!  Global fields can be accessed from anywhere even without relationship.  ExecuteSQL() and dynamic value lists cuts down on their use a bit but they are still an invaluable tool.  I keep most globals in a Globals table just for convenience unless one is needed for relationship - they are perfect for dynamic relational filtering (with pop-up of list attached).  Globals are specific to the current User so you can provide them their own 'lists' such as IDs of selected records. 

 

A field is required to accept User input so globals are used in Custom Dialog to ask for input and, as in this case, for performing finds.  So yes, same global can be used in other places with different script attached or different value list attached.  Keeping a few gScriptTxt and gScriptNum fields around which are re-used frequently, is handy although some of the more regular globals will be named specifically such as gClientID just to help keep them straight.  If you search here you will find many discussions about their limitations, benefits and uses.

 

Globals are cheap (and that is not a personal judgement of them).  I love cheap.

 

Also a word of caution in their multiplicity ... keep them straight otherwise you might use gScriptTxt for a portal filter then use it in a script holding a different value and the portal records will disappear and scare the bejeebies out of your User.

[db_tragic]

Thanks again LaRetta, it's starting to come together nicely now (my early understanding of globals that is). In the script you used,I gather that the expression "New Record/Request" reverts to the 'New Request' function whilst in find mode, and 'New Record' in browse mode.

[LaRetta]

Yes, you will notice several script-steps are multipurpose. And some work even though not clearly indicated, for instance Get ( FoundCount) and similar works in Find to return the 'request' equivalent. Notice '/page' as well for when in Preview mode. :-)