Where do you OFTEN use 'set error capture [on]'?

[kennedy]

Looking for some wisdom from you experienced guys...

Where do you OFTEN find that you need to add 'set error capture [on]' and handle the errors yourself?

I know *how* to do this... but its not clear to inexperienced me where there will be errors that I don't want to just let through as-is. Or worse... places where there are errors that cause misbehaving *without* any error messages (e.g., Modify Last Find just fails to work when it has an error... no error message, just nothing... ick!).

From searching the forum, it appears its often used with:

Modify Last Find

Perform Find (when doing canned finds, rather than user-specified ones)

Opening Files

Modifying fields/records that may be locked

What else should I be looking out for?

Thanks! (Its almost time for me to start fine-tuning my new template before copying it to all the files in my database.)

[Keith M. Davie]

A lot of what ScriptMaker affords the developer is the ability to design soluitons where the client is navigated from layout to layout. One of the most common uses of the set error capture is with regard for a subsequent conditional as a navigation tool.

Example, a client enters something in a find layout. If a record is found, a conditional would navigate to a form view of that record. If more than one record is found, a conditional would navigate to a list view of the found records. If no records are found, where do you want that client to be? Back in the find layout so another search string can be entered is not an uncommon navigation. Or maybe navigate back to the layout prior to the find layout.

[Keith M. Davie]

Oh, and one other thought.

For a working example I recently contributed a sample file to a thread. While the solution I offered was not as efficient as that offered by tdignan (get his attachment as well), my solution does provide a working example of using the set error capture.

[LiveOak]

I set User Abort off and Error Capture on at the beginning of virtually every script. This prevents the user from interrupting scripted processes and traps errors so that the user doesn't see any dialog boxes I don't create. Unfortunately about 80+% or any fairly complicated scripting is exception handling. Trapping and testing errors allows graceful recovery from FM errors by taking the correct action, routing the user back to an appropriate place in the process and providing an explaination of what happened.

-bd

[CobaltSky]

I agree. The default error handling provided by FMP is rarely of much use to the user (even in those cases where it provides an appropriate set of alternatives, it still leaves the user none-the-wiser as to why the error occurred or what to do about it).

This is not a criticism of FM per se; it's just that default error messages/responses have their limitations, so in most scripting situations it is desirable to turn off the more clumsy defaults and provide informative, 'context sensitive' and 'intelligently responsive' hand-coded alternatives.

Makes for some late nights wrestling with the Clunky ScriptMaker interface, though (when oh when will they enable copy/cut/paste of steps within/between scripts!!!).

[Keith M. Davie]

Re: "when oh when will they enable copy/cut/paste of steps within/between scripts!!!"

Well if one already has a script which is ~80% exception handling, and those exceptions are what one needs, one can import that script and deal with editing only ~20%.

And yes, it would be convenient to be able to copy and paste scripts and calculations.

[CobaltSky]

Well yes, like you, I was very pleased when script importing was introduced with v5.

But... what one finds with some frequency is that rather than having a script with 80% of the error handling required for the job at hand, one has two scripts with 40% each - or perhaps 3 with 30% each.

And yes, I know one can edit them all, and then line them up to be called as sub-scripts from a 'Master' script and other kindred lateral solutions.

But in a sense all these options, fine though they are in themselves, are still work-arounds and it would still be a good deal easier, simpler, tidier and more efficient if we could just cut and paste blocks of script steps in the first place.

[kennedy]

Glad to hear its not just me thinking cut'n'paste oughta work. I figured it must be an OS X bug... never dreamt they would have thought that a good design idea... I am beginning to feel like I am in college class with my over-zealous Pascal teacher who would've happily chosen a language that not only had no 'goto', but also had no way to cut'n'paste (which is just a mechanism of the devil, allowing you to write lousy code rather than subroutines).

Oh, but she'd never have accepted a language whose subroutines didn't take parameters! Or where local variables are all defined as globals!

Enough reminiscing...

[kennedy]

I set User Abort off and Error Capture on at the beginning of virtually every script.

Really? Ouch! I thought I just about had my template ready to combine with my all-but-finished file/field designs... guess I am still only halfway there. [sigh]

Soooo... neither FMP manuals nor the Coulombre/Price book go into that level of error checking. Nor do any of the many templates and examples that I've plucked from here, layoutmode.com, and so on. Can you guys point me to some templates that do a good job of error checking?

Thanks.

[Keith M. Davie]

The above mentioned Scriptology offers this advice, "...the integrity of any structure, including that of a FileMaker Pro database, depends entirely on the strength of the foundation. The foundation in this case is your ability to understand the operation of each and every function....Before you move onto complex calculations that integrate multiple functions, it is important to understand the individual functions themselves."

While this particular passage is about calculations, it applies equally to writing ScriptMaker scripts.

So in answer to your query about templates, the best ones are the ones you make yourself out of your understanding and the demands of your design.

Speaking of teachers; among other things my teacher said, "If you don't have time to do the job right, when will you find the time to do it over?"

[kennedy]

my teacher said, "If you don't have time to do the job right, when will you find the time to do it over?"

Absolutely! Which is why I have spent so much time just working on my template (and pestering this forum), determined not to move forward on all the real files until I've got the template done right... 'cause I know it'll be N-times as hard to fix later.

And thus...

So in answer to your query about templates, the best ones are the ones you make yourself out of your understanding and the demands of your design.

Understood. But in this case I am trying to learn as much as possible from you smart guys up-front by looking at *your* stuff, so that I can get that learning into my template *before* I get my stuff into practice (and discover those deeper demands on my own).

My template is getting sooo nice, I almost cannot stand to wait any longer to put it together with my field/record designs. (Thanks! )

But I know pulling the trigger early will be COSTLY later!

[Todd Dignan]

Just a little tip "while developing, if your going to use allow user abort OFF" make a back door. In my files I will usually make a script name BackDoor. The script halts the script if a modifier key is held down.

if ["Status(CurrentModifierKeys)=1 (shiftKey)

Halt Script

End if.

This works great in testing loops.

[The Bridge]

A good tip. I take this a step further by trapping for Status(CurrentGroups), e.g. If (PatternCount(Status(CurrentGroups), "Developer") = 1), where Developer is a standard group I attach to the master password of a file. This prevents users from accidentally falling through the "back door".