1 2 Previous Next 17 Replies Latest reply on Apr 12, 2016 12:54 AM by dddan

    Perform find

    TobyGross

      When i perform a script with perform find in it, it works well when it finds something but when it doesn't find anything it prompts the message that  nothing matched the find can I have that not appear when this script is performed?

        • 1. Re: Perform find
          RickWhitelaw

          Use Set Error Capture (on) at the beginning of your script to prevent the dialog from showing. Then use If getLast error = 401 to have the script do what you want when it encounters this error. I'm not at a computer right now so look in the script steps reference to get the proper syntax.

          • 2. Re: Perform find
            TobyGross

            Wow works great

            THanks for the help

            • 3. Re: Perform find
              taylorsharpe

              A good best practice is to:

               

              Enter Find Mode

              Set field(s)

              Set Error Capture (On)

              Perform Find

              Set Error Capture (Off)

              If ( Get ( FoundCount ) = 0

                Do some error trapping for no found records

              End If

               

               

              Placing Error trapping around any function in FileMaker will return an error instead of stopping the script.  You can capture the error with Get ( LastError ) and decide what to do with the error such as:

               

              Set Error Capture (On)

              Do something that might Error

              Set Variable ( $Error = Get ( LastError ) )

              Set Error Capture (Off)

              If ( $Error > 0 ... or maybe = to a specific error #)

                 Do some error trapping

              End If

               

               

              Just remember when you turn Error trapping on, you need to turn it off and you must capture the error before turning Error capture off. 

              • 4. Re: Perform find
                dddan

                Hi Taylor

                Interesting. If you don't mind me asking, why do you want to switch error capture off again? I run most of my scripts with error capture on, and look for errors when I need to know they happened, but usually want to avoid that end users in the case of a long script can step out because FM gives them that option when error capture is not on.

                Curious why you prefer to switch it off again. What's the advantage?

                • 5. Re: Perform find
                  erolst

                  dddan wrote:

                  avoid that end users in the case of a long script can step out because FM gives them that option when error capture is not on.

                   

                  Are you maybe confusing Set Error Capture with Allow User Abort?

                  • 6. Re: Perform find
                    dddan

                    yes, you're right! I almost always use them together but still, question is there. By capturing the error you avoid that the end user sees a standard FM error which are not very friendly worded, and sometimes not relevant to the end user. So I was mainly wondering if there was a specific reason why you would set error capture off again, instead of switching it on and off again.

                     

                    Also, for Toby, there is no need to actually capture the error with the get error returns >0. If you don't mind that if a user is presented with zero records after a find the only thing you need to do is set the error capture on. I have the feeling that that is what he wants. He doesn't really want to create a custom message I think.

                     

                    Thanks. 

                    • 7. Re: Perform find
                      RickWhitelaw

                      Nobody is suggesting a custom message. We're suggesting he capture the error and act on it.

                      • 8. Re: Perform find
                        keywords

                        dddan wrote:

                        So I was mainly wondering if there was a specific reason why you would set error capture off again …

                        It seems to me the logic is to leave FM's inbuilt error trapping in place unless you have a specific reason to suppress it. Thus, if you HAVE a reason (e.g. to send a script down a specific path in the event of an error) then once that need has been met return to default error trapping until the next need arises. If you script this way you are building in error handling consciously, at each point at which an error may arise. If, on the other hand, you simply set error capture on at the start of the script and leave it that way throughout you may easily overlook the need for specific error handling routines, or even skip past errors that FM would have thrown up if error handling had not been suppressed. Also, as I understand it, the setting passes to subscripts, which could produce a problem you fail to anticipate. For example, if in a script you leave error capture switched off, but then switch it on for a specific reason in a subscript and then don't switch it off again, the main script will then inherit the suppressed error state for the balance of the script, which may cause issues you did not intend. For all these reasons it is best practice to follow the routine: switch on; handle the error; switch off.

                        • 9. Re: Perform find
                          taylorsharpe

                          dddan wrote:

                           

                          Hi Taylor

                          Interesting. If you don't mind me asking, why do you want to switch error capture off again? I run most of my scripts with error capture on, and look for errors when I need to know they happened, but usually want to avoid that end users in the case of a long script can step out because FM gives them that option when error capture is not on.

                          Curious why you prefer to switch it off again. What's the advantage?

                           

                          It is a programming best practice like clearing variables after use.  One reason is is that it keeps grabbing errors, loosing the previous error, and when you look at it, you don't know which error it has been trapped if you just leave it on for the whole script and it may be trapping an error you didn't want trapped.  Most everything that has an off and on should be turned off after using such as animation or allow about, etc.  Everything should be intentionally used and turned off when not using it.  For example, I make sure all scripts end with an Exit Script as well as try to prove a useful script result in case this script is called by another one. 

                           

                          It is sometimes easy to get sloppy with FileMaker scripting since it isn't really programming and FileMaker lets us get away with it.  But in regular programming languages, even setting a variable means you have to first create the memory space for it to store something in it and when you finish using memory space, you have to get rid of it or your program will continue to gobble up memory.  Fortunately, FileMaker does the memory management for us in scripting.  But just because FileMaker lets you do some sloppy work doesn't mean it is a good idea.  Following computer programming best management practices is not only good, but helps future developers using your work.  And one of my biggest pet peeves are those who script without commenting.  No, you don't have to comment everything, but you should comment major script sections as to what their purpose is as well as a comment at the top explaining what you are doing.  

                           

                          You might want to check out Overview - Coding Standards - FileMaker Coding Standards to see some FileMaker suggested standards and best practices.  There is some good thought that went into a number of those standards.  Not that I use or agree with all of them, but a number of them I certainly do. 

                          • 10. Re: Perform find
                            dddan

                            Hi Rick,

                            Yes, you're right, it was late when I wrote that, and should have written 'custom action', but because this discussion started with creating a find request, for me it is good practise to first inform the user that what he was looking for did not give an results before doing anything else, hence the custom message. Otherwise users might wonder 'huh, I asked for Y, and the software gives me Z'.

                            But this is also the reason I hardly ever take action when a Find request returns zero records. Most of the time it is clear to the user that if the software doesn't return any records, that there were no matching records. I'll just suppress the message.

                            But this is typical something that depends largely on the kind of solution.

                            • 11. Re: Perform find
                              dddan

                              Hi Keywords, Taylor,

                              Thanks for the input, it is always good to read other's opinions on these matters. I do agree with a lot of points you make, and during development I might have error capture off. But once I confirm that something works, I do not want users to be confronted with FM messages. And the Script debugger is a great tool for tracking errors.

                              Re; comments I'm fully with you! Both for other developers but even for yourself, if you need to revise your work years later and wonder what a script is doing exactly.

                               

                              I am familiar with the Coding Standards, but just like you, I am afraid I do not agree with all of them. I think it depends a lot of the type of solutions you build, and what the requirements are, if all of them make sense. But that's a different discussion ;-)

                               

                              Thanks

                              • 12. Re: Perform find
                                Mike_Mitchell

                                dddan wrote:

                                 

                                But once I confirm that something works, I do not want users to be confronted with FM messages.

                                 

                                What if an error occurs you didn't find during testing? How will you know it happened? And how do you know how the script will react? How will the users even let you know if they don't see a message?

                                 

                                While your motive is admirable, you're assuming infallibility in your testing program. That's dangerous. Users are quite creative at finding things you didn't.  

                                • 13. Re: Perform find
                                  dddan

                                  Hi Mike

                                  Haha, you got a point there. But in reality there is  often not much difference. I guess it also depends on what kind of clients you have, and most or my clients are 'real end users'. Even if they see a dialogue box stating an error and I ask them 'what did it say?" they say 'I don't know, I just clicked OK/cancel. (I have done years of training people how to use software, and nine out of ten users do not read messages, they just click the default choice to make them go away ;-)

                                  If a script doesn't do what they expected it do then they'll let me know, 'we pressed print and nothing happened' and then I'l look for the error, either by switching error capture off temporary, or by using the debugger. (which displays all errors anyway)

                                  Thing is that many things that FM considers 'errors' are not really errors from my point of view. I just need to know if there were zero found, if there is window open with the name print, etc. By continuously switching error capt on/off I feel I just clutter my scripts. But don't get me wrong, I am not saying my method is better, I do understand the possible pitfalls. That's why I asked why people who do this switching... Live and learn... ;-)

                                  • 14. Re: Perform find
                                    RickWhitelaw

                                    One thing I sometimes do is if there are no records is create one and set a field.

                                    1 2 Previous Next