Sounds like you have another script that is paused--often this is done to hold a new window as a kind of "modal dialog" for entering data such as search criteria. Might that be what you have here?
If you want the termination of one script to end all other scripts that might be paused at that point, make Halt Script the final script step.
Here is my script:
Go to Layout [ “Search Form” (HSVIDEO) ]
Set Error Capture [ On ]
Enter Find Mode [ ] [ Pause ]
Perform Find [ ]
If [ Get(FoundCount)=0 ]
Go to Layout [ original layout ]
Show Custom Dialog [ Title: "Info"; Message: "No Search Results Found"; Buttons: “OK” ]
Go to Layout [ “Browser-HS Graphical” (HSVIDEO) ]
Sort Records [ Specified Sort Order: HSVIDEO::TITLE; ascending ] [ Restore; No dialog ]
Go to Record/Request/Page [ First ]
Exit Script [ ]
The third step is to enter Find Mode Paused after landing on the search form for the user to fill-in search criteria. I have a "Continue" button on the form to click to resume the script. Am I using the Find Mode Paused incorrectly which is causing my problem?
Enter Find Mode [pause]
does not appear to be the issue here. I would guess that some other script is paused. This could be due to a script trigger performing a script after one of the go to layout steps if you have a script trigger set on one of the layouts involved.
Phil, you were right (of course). I originally had my search script set up as a trigger when the search form opened but decided to not do that and thought I had unchecked that trigger. Once done, the problem went away. Thanks.
By the way, I am so accustomed to using the convenient "Back" and "Forward" button in browers, is there any built-in function that will permit this type of navigation in FM? Let's say I run a Find and have a layout listing those records, then I display one of the records for more detailed information, but then I want to back-up to that previous search results form to display another record from the same search.
So instead of running another search putting in the same criteria over and over, I keep wishing I could just hit a Back button to get back to that original search results display.
This can be scripted fairly easily.
You can use code like this:
Set variable [$$PrevLayout ; get ( layoutName ) ]
In a script just before the go to layout step takes the user to the next layout.
Then you can use Go to layout with the layout name by calculation option to return the user to the previous layout by using $$PrevLayout as the sole term in this calculation.
Thanks, I will play around with this over the next couple days.
Hello Phil, another question has come up on this script. If the search returns no records, I am wanting to modify the pop-up dialog box to ask the user if he wants to try another search. If "Yes" then how do I restart the script from the beginning for another try? If the answer is "No" I can just return the user to a menu or show all records in a list with a preferred sort and Exit Script at that point.
I just am not sure how to do a restart on the script while it's in the IF step with no records found. I used to write DOS batch files and I would set a lable at the beginning (something like :top) and so if the answer is "Yes" just have a statement that says "goto top" but it's not that obvious to me in FM.
A script can call itself. This is called "recursion".
So your script can test to see what button in the custom dialog was clicked and if the "yes" button was clicked, a perform script step can call this very script to start the process over again.
BTW, I prefer not to set up scripted finds like this as I like to make things a bit more user friendly than just dropping into find mode and pausing. I set up a search layout with global fields for entering search criteria. This, among other things allows me to add drop down lists designed for find criteria and I can set up two fields for a range such as a search for records dated from date 1 to date 2. This allows me to set up two scripts. Script one takes the user to the layout. Script two takes the data in the global fields and uses set field steps to construct the find request(s) needed and performs the find. I'll even use the New Window script step in script 1 to pop up the search layout as a small "search dialog".
With that setup. The "do you want to search again?" question is in script 2 and I just need to use perform script to call script 1 to try again.
I pulled a book ("Filemaker Pro 10 The Missing Manual") and looked up recursion and there was no applicable example or topic for what I am trying to do. I thought maybe there was a function with that name but guess not. Your preferred method is a little over my head right now, Phil, but I will keep plugging at it.
I tried the Loop/Exit Loop within the IF (record count is zero) area based on whether the user selected 1 ("Yes" let's try another search) or 2 ("No" get me out of here) with all kinds of combos of IF/ELSE IF, LOOP, EXIT LOOP IF, but no matter what I do it either says one of my END IF's is not valid and once I whittle them down it then says END IF missing so I'm just going in circles.
If you have time, how do you do a recursion with my basic script just trying to restart the script if the user wants another go at it?
All you need to do is add the perform script step to your script and have this step refer to itself.
If your script was named "Find Records".
Then add a Perform Script step to your script that performs "Find Records".
Well actually I tried that first and in the past as well, and kept getting an error message about must create or have records displayed or something like that. I just tried over and over to re-create the error to screen scrape for you but now of course it is working flawlessly.
If the error re-occurs I will post it here.
Chances are, that the past error came about from script steps added after the recursive Perform Script step--which may have then been performed in an unexpected context--after the recursive call completes. When you set a script to call itself like this, FileMaker puts the first script on hold, runs a new instance of the script and then returns control to the first instance of the script at the point immediately following the perform script call. In the case of this last script, the only thing that happens after the perform script is that the script terminates so there's no chance for that to be an issue.