Jump to content
Salesforce and other SMB Solutions are coming soon. ×

zippscript 2.0 to the rescue

Maarten Witberg

Recommended Posts

There's a saying about plugins and it goes: "Plugins? Just say NOoOOOoOOoOoAAAAARGGHNo!"

Of course I am a law abiding inhouse guy who lives by these rules. Why? Because plugins double your version tracking hassles. Because plugins have bugs. Because they cost ya. Because if you need a plugin to get something done, you're not doing it right. Because real developers don't use 'em. Do they?


So I kept them at bay. Until now. I ran into one of these "it's an unstored calc you moron, you can't use it in a relationship" situations. A situation aggravated by "And auto-enter calcs are out too because if you manage to get the current record to update with it (hah! with a min(selfjoin::recordID) no less! ), you'll never see it update in all the related records as well. Duh." And by "yah well scripted data entry could do the job but that would mean seriously reconsidering the UI, that's a no-no too."


But there is ZippScript 1.1 a nifty little plugin I downloaded some time ago but never used because of see above. Am I finally going to burn my fingers on that one? Lessee what's on the internet about it. And there it is: ZippScript 2.0, released this august.


Zippscript 1.1 essentially packed two functions: the actual trigger function and a function that returns version info for the plugin. Where 1.1 has only a shortish readme text file as intro and a simple demo file, version 2.0 has a full fledged intro/demo file with bells on. You just put the plugin in the extras folder, start filemaker, and there ya go. The two functions of version 1.1 are still there (and frankly, just the one (zippscript_Performscript) will do for me for now). Scripts will trigger on field modification, record commit, field display (haven't tried that one), and even on mouse over. The latter trick may make some people sit up straight but neat though it is, it's a little bit lame. It makes use of the tooltip function (so it's only available in version 8) and the demofile reacted quite slow. If you're expecting instant mouse-over effects such as any website will offer you, you're going to be disappointed.

Not so by the big new feature version 2.0 has: a script scheduler. You can set a timer, it will run in the background and you can just keep working as if nothing else is going on. And at the specified time there it is, your scheduled script starts to run. It even puts a dialog box up front if you're in another file.

Then there are some add-on features such as the ability to disable and enable the script triggers (so you can modify field content and not have the script trigger), and some handlers for the scheduler (cancel, get state).


Getting it to work is not difficult, it neatly flows into the try first, learn how it operates later style the whole of filemaker has. You do need to familiarize yourself with the parameters, some of which are optional.

Let me tell you it took longer to write a working script than to implement the trigger that calls it.


Now I made only a first run with it, created my own test file to see it in action, then rushed to get this post out. There may be hidden flaws but I didn't spot any so far. It has just come to my rescue and I can see many moments in the future where it will prove useful. I'm just a hack, I need dirty tricks now and then. more often, even.


So go out and get this while it's still free! It's version 2, for any software that's the version number everyone needs and is just perfect. 1 is just trying it out, everything after version 2 will go the way of Microsoft Word (So why am I in FM8 now Oh Really! ).

Just support this developer OK? His name is John Kornhaus, he has a paypal button in the demo file, poor sod.






test runs on PowerBook G4 / 1.33 ghz / OSX 10.3.9


Link to comment
Share on other sites

filemaker.wikispaces.com mentions this :


Since FileMaker is not designed to handle event-driven scripting, adding it via a plugin may have unexpected consequences.


If you are running a script that updates a field and then that field change causes your script to fire it can in some cases result in FM crashing. This happens most often when there are layout changes happening in the 1st script and maybe some calculated field changes.


When you make a change to the database, there are certain operations that FileMaker does internally to make that change. It does things like cache management, screen updates, field validation, cascading calculations, etc. in order to make FMP behave the way we expect it to. The problem with script triggering is that the script gets triggered in the middle of all of these operations.


So, if the script that is triggered does certain things, it causes FMP to behave in ways that FMI cannot predict, thus causing the application to crash. This would be things like (but not limited to) moving to another layout, changing context, and changing records.


ZippScript will allow you to disable the trigger to modify a field in a second (non-triggered) script, and thus prevent some of the crash causes mentioned here.

Nevertheless I would appreciate if anyone could comment on these warnings.




PS edit september 9, 2006: the wikispace referred to in this thread no longer exists.

Link to comment
Share on other sites

Hi Kjoe,

I've no idea who wrote the passage you quoted above. However I'm sorry to say that it contains an abundance of mis-information and just about nothing that is accurate. The page it comes from contains numerous other basic errors of fact.


First of all, it's not true that "running a script that updates a field and then that field change causes your script to fire it can in some cases result in FM crashing". The situation described will produce an endless loop, which is different from a crash in several important respects, not least of which being that it can be escaped without harm by terminating the script - something that the writer is apparently unaware of. Moreover this would occur not as a risk posed by a plug-in or script triggering per se, but as a risk posed by poor coding. There are plenty of native ways to get a script stuck in a loop which don't involve the use of either plug-ins or triggers - but competent developers don't generally have trouble avoiding them - and for that matter, are usually able to distinguish between them and a "crash".


The passage you quote then goes from bad to worse by referring to "certain operations" and suggesting that these may pose a problem for script triggering. Plug-in calls to trigger scripts, however, queue the scripts to run at idle - ie after internal "housekeeping" tasks are complete - so there is no "problem" in this regard.


The quote then goes on to talk about a triggered script causing FMP to behave in "ways that FMI can't predict" and suggests that this can cause the application to crash. With respect to plug-in script triggers this, too is complete nonsense. Whilst it's true that a queued script may either be cancelled and not run (eg if the file has been closed) or may commence its run in a different context from that in which it was triggered (eg if the user has changed records, windows or layouts etc) none of these situations causes FileMaker to crash.


What *is* true (but not mentioned in the quoted passage) is that it is incumbent on the developer (not FMI) to manage context when using any method (plug-in-based or otherwise) to trigger scripts. This is simple commonsense - it is incumbent on the developer to anticipate the various uses of the code s/he provides and adjust accordingly.


You've asked for "comment on these warnings". Putting it about as politely as I can, I'd have to say that the statement is comprehensively in error. Sorry.

Link to comment
Share on other sites

Hi Ray,


There's no need to say sorry... I'm glad it wasn't I who wrote it. It did seem strange to me that a triggered script could be able to shoulder its way into running procedures. There seems to be no mention of it anywhere else (that I could locate) even though script triggering plugins have been around quite a while. But I found it worrying enough to want to check. Hence my post.


On a broader issue, it does pay to be wary of internet sources as they can contain so much misinformation. If there's no one to correct the matter, it just sits there. In busy forums like ours, nonsense is dealt with quickly and efficiently.


for which I am, of course, indebted to you.





ps I just noticed you have made a major edit in the wiki I referred to. man you're thorough! :cool:



PS edit september 9, 2006: the wikispace referred to in this thread no longer exists.

Link to comment
Share on other sites

  • 7 months later...

kjoe - this looks VERY promising, but I'm thick! (And anything but a Pro.)


I'd need to choose a layout on the basis of a lookup or calculated value. Your documentation makes it clear that this is exactly what zippScript does, but I can't figure out how to implement it.


I _am_ looking at the examples, but but but...

Link to comment
Share on other sites

I believe something like this should trigger the script (as an auto-enter calc).


scpt=zippScript_PerformScript( Get( FileName ); "YourScriptHere" );

Link to comment
Share on other sites

  • 10 months later...

I'm not sure why. I followed instructions to recall the scheduling script in the called script, but it keeps looping. I tried a 5 minute pause/resume step to assure that it was away from the scheduled time. The script ran at the called time, then ran again 5 minutes later.

zippScript_ScheduleScript( tableName::Time; "filename.fp7"; "Create Report" )

Link to comment
Share on other sites

  • 4 months later...

I don't understand why this works. The zipp function is declared but never called. It does work for me, by the way. I am using it in a simple Session model with one ui layout. When I update a field in a portal, I need to Refresh Window [Flush cached join results]. This will update a related field in another portal. ZippScripts works great because the window will refresh upon exiting the field. I'm just not clear on why it works in the Let statement above (which, by the way, is the exact calculation I use to get it to work in my db).





Link to comment
Share on other sites

As far as I understand the magic it's simply because the let() statement is triggered by filemaker, because it's in an auto-enter. The first declaration of the let() says a parameter is equal to the Zipp function. This makes the plugin call the script.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

Terms of Use