just add AND not isEmpty (TrustReports::Trust Company)
in the exit Loop if like so
exit loop if ( not isEmpty (TrustPolicyReports::Report Date) AND not isEmpty (TrustReports::Trust Company ))
If "" // (I usually start all my if clauses with an empty if. Makes it easier to copy/paste conditions. Just a preference)
Else If ( IsEmpty (TrustPolicyReports::Report Date )
Show Custom Dialog [ Title: "Trust Report Requires a Date"; Message: "Please press OK and then enter the date of this Trust Report."; Default Button: “OK”, Commit: “Yes” (cancel button?)]
exit loop if cancel?
Else if ( Something else is wrong)
Show Customer Dialog ( something else is wrong)
Exit Loop If 1
(deal with cancel?)
Assuming your script is triggered by the user clicking on a button (and not part of another script)...
Since you are using dates I would do this;
Date Field A _______
Date Field B _______
Script Performed by button click:
If isempty Field A
Dialog please enter a date and then click the button again
Go to Field A select perform
If isempty field b
After both fields pass your test you can now continue with what you want to do....
Note that if you use conditional formatting you can color the background of the two fields if they are empty to draw attention to them...
This method to me is better than using a dialog since you can now use the FileMaker DataPicker and also any design conditons for the field. Making it a date field etc. ensures a correct date.
Also it does not require a loop and it cancels itself if needed.
You can also use various hide and show stuff to tell the user to enter the field and not show the button until afterwards...
I used to put a buzzer in the seat cushion to encourage the user to do it right...
The only reason for pause script and the loop would be if the script needs to retain the Script Parameter or variables.
The loop is probably the only trick without placing stuff in globals.
So here's the loop, assuming a button performs Resume Current Script or the user clicks that thingy if it's shown in the toolbar.
Is seeing that "Halt Script" step giving anyone else hives, or is it just me?
Unless... you're absolutely sure that no matter how this script will be used in the future, it's okay to stop any other scripts that might be running... like for instance the script that's supposed to get us back to whatever layout we were on when the whole thing started?
I don't think I've used that step since FileMaker 2.
Just sayin'. FWIW.
Ugghhh, how did it end up there?
Thanks for catching that one, Chris.
Substitute proper logic.
Sent from my iPhone
Thanks for all your help!
With a script along the lines already suggested, I suggest you add an additional test:
If ( test to see if BOTH required fields are empty )
– a suitable message re two missing required items
Else If ( there is a date, but no company name )
– a suitable message re missing name
Else If ( there is a company name, but no date )
– a suitable message re missing date
Else ( i.e. both fields have data )
– the rest of your script
That format gives better guidance to the user as it saves the user who has supplied neither value, being told only "you must supply a date (or name)", supplying it, then being told about the other missing value.
I sort of strongly dislike the pause and resume in routines. But that's me.
You can validate (field level)
You can trigger (layout level)
You can test ("submit" button)
and so much more.
The reason I say no more pause, is that it is an UNCOMPATIBLE step for fmserver, fmgo and web (previously IWP). Also, it can go wrong for so many reasons and leave the user in limbo, frozen loops, etc.
I'm with you on that.
I get same shivers with pause script as Extensitech gets about Halt Script.
I like loops for iterations over a known index of larger data, in the above case they're difficult to write, read and debug.
And for all the reasons you mentioned: incompatibility.
It really is kind of FileMaker toolbar thingy, which is powerfull but scares the crap out of some users I come across.
Another method :-)
Wait for enter
Set Variable $message = if ( IsEmpty ( field1 ) ; "Please fill in last name ¶" ; "" ) &
if ( IsEmpty ( field2 ) ; "Please fill in e-mail¶" ; "" ) )
Exit Loop If ( IsEmpty ( $message ) or $cancel )
Show Custom Dialog ("Sorry dude you missed something " ; $message )
Neat all these different approaches!
Happy Coding :-)
I'm (genuinely) curious how you'd avoid pause in this case, since we need the user's input before continuing.
I don't think this process could take place on a server, anyway, since we need human input, whether through a dialog, pause on a layout, or whatnot.
Still, I'm not crazy about having the user in a paused script, either. I manage to avoid it most times, but sometimes I just need to ask the user for some info in the middle of a script. Since the user has to be involved, server compatibility isn't the main issue. However, your concern about "limbo, frozen loops, etc." is valid.
The thing is, I still need to 1) get the user to the point where I ask the question, and then 2) do something based on their answer. In some form or another, I need to "lock up the user" somehow so they don't wander off without part 2 ever happening. Without pause, I think my options are:
- create a complex dialog, or set of dialogs, for each time this need arises
- put them in a modal window, end the script, and then pick up part 2 when they hit a button
- put them in a non-modal window, end the script, and write part 2 so as to regain whatever context was necessary to complete the steps in part 2
None of these, on the surface at least, seem as good (or better) than just a pause/resume.
However, to be clear, this isn't some sort of sarcastic, back-handed criticism. I really am looking for other, better ways to handle this scenario. Currently, we have an "input" mode (call it a flag to avoid messy details) where the user is paused and can't commit the changes or perform other scripts until they hit cancel or ok. It works "well enough" but there's the scenario (for example) where a phone rings while they're here, and they need to record the call and don't have time to complete the original task first. I'd like to devise a method where the user is free to go do other things, but we still "hang on" to what's going on in the original script.
Can you share some ideas on this topic? This might warrant a new thread, since I'm leading us way of topic here, but you've hit on something that's been on my mind a lot lately.
Wait for enter
Are these the new script steps introduced in version 14? I certainly like the last one.