zippScript Challenge

[Rob P]

To answer an earlier question, no I am only referring to the 3 free plugins zippScript, myFMButler's DoScript and Software 4 Human's Eventscript.

Of course, right now I'm most intrigued by DoScript. But I'm banging my head around this one. There are 2 main differences between what your example shows, Peter, and what I've done. Yours is an all in 1 script and it's using literals, and mine is modular using variables, oh, and Yours works and mine does not. I've included a simplified version here, what am I doing wrong?

DynamicDoScript.fp7.zip

Edited November 22, 2006 by Guest

[Peter Wagemans]

Hi Rob,

Just one thing is wrong.

Put the contents of the $scr variable between double quotes and you're all set.

The myFMbutler DoScript plug-in evaluates the trigger.

Cheers! -- peter

[Rob P]

WOW, progress! OK, I totally hosed the variable $scr because I did not realize that the entire if statement was enclosed in "".

BUT, I only got it to work when I enveloped all the set variable script inside my main looping script. When I tried it in the modularized version it did not work. HMM but I'm thinking maybe I need to just do a little rearranging of the scripts.

brb

[Rob P]

WHOOP, DE IT IS!

I placed the sub: charge script in the main looping script passing it the script parameter....it works!!!

YOU ROCK, PETER!!!!

[Rob P]

Here's a copy of the revised file with an added example of exporting all records.

DynamicDoScript.fp7.zip

[Genx]

Oh well, thanks for the effort and the great help anyway!

I've noticed that FM can be b******s in general about issues with their software. Looks like i'll be moving over to DoScript for a while :P

Edited November 23, 2006 by Guest
self censorship

[Rob P]

Yeah, there are things the can be very slow moving on. I've been asking for input masks since version 1.0, how many of you still have calc fields to properly format a friggin phone number? But, there are times to do listen (variables).

[omegagoh]

Dear All,

My apology for mistaken Rob's message posted on 11-17-06 02:11pm.

It began as, "Yes, it's similar to Events but it's free.". That gave me the impression that Rob had tried EventScript (from Wave in Motion) which wasn't FREE.

[Genx]

Omegagoh, don't have to appologize.

But the EventScript that we were referring to is made by soft4humans (the creator uses the alias homer on this forum). I was unaware that there was another plugin called "EventScript".

Just as a general note, thanks for the input from both Peter and Gaston during these discussions, shed some light on a few issues that have concerned me for a while .

[Homer]

To make the things clearer; the plug-in from Waves in motion is named "Events" and it costs 129$ for a single user license. This PI exists for many years and is also available for pre-7 FileMaker versions.

The plug-in from Softs 4 Humans Inc (I'm the founder and president ) is named "EventScript", is only available since FM7 and it is free of charge. If you really like our PI, you are invited to make donations.

[Genx]

RE: Complaining.. Who do we complain to and what exactly would this complaint say?

[Peter Wagemans]

For bugs:

http://www.filemaker.com/company/problems.html

For feature requests:

http://www.filemaker.com/company/feature_request.html

[Genx]

Lol wow,

In all the time i've complained it's never been to the right place

Those two are going straight to my bookmarks

Cheers!

[Genx]

Boy did posting that feel good!

[Peter Wagemans]

I don't want to spoil the fun Genx, but we here call it "the black hole".

But it's still "the place to be" if you want to air your frustration.

Thanks for pumping up the statistics, it's a hell of a job, but somebody 's gotta do it...

[Genx]

Lol yeah,

I don't actually expect anything to be done about it it's just a good place to as you say "air your frustration".

[Søren Dyhr]

I don't actually expect anything to be done about

But isn't is so that one persons felt shortcomming, is anothers bread and butter ...I haven't felt this a problem in the first place, but as an oppertunity to manipulate the scripts execution in recursive scripts. We have ever since fm2.1 been scared away from recursive scripts ...but the overhead was changed considerably with fm7 so stack overflow was much less likely to occure!

I know that both rebellion on theft is much more likely to be committed by males beyond the age of 27 ...but might it be so that thier minds might be toxicated into this hubris, and making them less inclined to work with whatever is availiable by ingenuity and hessitation???

--sd

[Genx]

Im not complaining about stack execution or recursive scripts, i'm complaining about FileMaker never returning to SafeIdle mode on Windows and therefore simply making it a lot harder for me to do anything without interrupting my users -- i.e. interupting them while they are entering data. As for you never "feeling it as a problem" -- It's a windows issue only so i doubt you would.

You tell me how to take advantage of not knowing if your user is actively entering data or not and then you can tell me that my over reaching pride is blocking my sight and not letting me see what wonderful advantages and opportunities are in front of me and so on and so forth.

[Rob P]

Just an FYI, I've had to ditch my variable script idea. I can't put my finger on it but I can't get it to execute the variable script consistently. I could be running just hunky dory and then pow, it just decides that it won't execute anymore. I don't have any more time to mess with this so maybe someone else can take up the reigns on it.

No, it's not a safe idle mode issue, I've got this occurring on a Mac as well as windows.

[Genx]

... Idle state has almost nothing if anything at all to do with calling recursive scripts... I'll play around with Peter's example file a bit more later and experiment and will let you know how i go.

[Søren Dyhr]

No, it's not a safe idle mode issue, I've got this occurring on a Mac as well as windows.

Well Genx is kind of right here, since the HUI recommendation from Apple talks of "forgiveness" in their metaphoric approach demanding buttons to a modal change. If this is a major shareholders trumphing a policy thru here is a good question or it's just is a chosen point of view to keep as much out of trouble as possible, is a very good question, read the Don Gentner/Jacob Nielsen I link to!

The commitment of a users entries in a multiuser environment is never negotiable in interpretation that way at least. Buttons can be set to terminate a previously running script even if it's paused with a sort of Trotskyist permanently being in one script at a time, preventing the call to hotline "...all my records had dissapeared" while being in findmode.

I have always regarded this as being outside of the filemaker realm and on your own when relying on thirdparty tools to emulate triggers found in other tools.

Filemaker is kind of closing this gap by instead having calc's and even custom functions and field level validations which other tools doesn't have. I would seek to make as much looping as posible a custom function instead, which both can be made into linking table as well as a calculated part of a field level validation.

I think it's important to recognize, that eventhough the validation is on field level, is it posible to trig the evaluation of such a calculated validation by a presence of a field where the validation is underneath, as long as just 1 pix of the field is present on the layout ...it's the layoutevent that pulls related values, looked up values ...which is the only real trigger filemaker have.

http://www.kevinfrank.com/download/county-highlight-in-portal.zip

But perhaps you should turn to Runtime revolution to produce interfaces in, that could speak to filemaker via IWP/CWP???

--sd

[John Kornhaus]

So what you would expect for a call stack should look something like

BTN: DO MY THANG

SUB: GO TO LAYOUTS

//start loop

//loop 1

Go to Layout X

SUB: Find All Records

//exit

//loop2

Go to Layout X

SUB: Find All Records

//exit

//loop x

Go to Layout X

SUB: Find All Records

//exit

//end loop

//exit script

//exit script

What I get looks more like

BTN: DO MY THANG

SUB: GO TO LAYOUTS

//start loop

//loop x

Go to Layout X

//end loop

//exit script

SUB: Find All Records

SUB: Find All Records

SUB: Find All Records

Hi, sorry I'm late to the party.... I don't visit here often and just ran across this question.

FileMaker will respond differently to requests to run a script depending on what it is doing at the moment. If it is doing something, there is nothing in the plug-in API that will let you break into that processing and force it to do something else (I consider this A Good Thing™). Requests to perform a script are queued and executed at the next opportunity. If the requests are made while in the midst of running a script, then the next opportunity will come when the script has finished executing.

If a request is made while FM is idling and waiting for the user to do something (no script is running, or a script is paused), then the new script can be executed immediately.

Soren's comparison to an AppleScript'ed loop is not really relevant here since he's already circumvented FileMaker's script scheduling by implementing the looping structure outside of FileMaker and simply making calls to the sub-script(s) as necessary. The subscripts will run properly interspersed with the control loop since FileMaker is idling and waiting for some incoming commands.

The same problem occurs in all three plug-ins mentioned here, because we're all using the same function call in the plug-in API to request a script to be run. We're all bound by the same limitations in how FM will honor that request.

But, there are some tricks we can use to work inside the execution framework that FM provides, and I think we can solve this problem with a little out-of-the-box thinking.

If we examine the problem, we'll see that the reason the sub-scripts are grouped after the control loop is that the request to run the script occurs while FileMaker is busy, namely running the control loop that is trying to call the sub-script. If we can delay making this request to some point when FM is not busy, say while it is paused, then we can trick FM into running the sub-script right away. This is exceptionally easy to do in zippScript 2.0 by calling

zippScript_ScheduleScript( Get( CurrentTime ); Get( FileName ); "ScriptName" )

The next time FM has time available, the schedule will be activated since the scheduled time has already arrived and the sub-script will be called. Since by definition FM isn't doing anything then, the script will run immediately rather than being deferred.

We can force FM to make some time available to plug-ins by inserting a Pause/Resume script step right after the call to schedule the script.

If you now try to run the looping script, you'll find that FM will pause indefinitely after running the sub-script (requiring a click on the "continue" button, or a press of the "enter" key), regardless of the delay you specified in the script step. I believe this is a bug and will report it, please do the same if you'd like to see this fixed in a future FM update.

This, too can be worked around by scheduling the script so that it will resume any paused script when it is executed. This fix required a slight change in the parameter list for the _ScheduleScript function; I have a beta of zippScript 2.0.1 available (Mac only at the moment) if anyone would like to test it. Email me, jkornhaus AT mac.com.

The final version with some updated docs and new examples will be available at http://homepage.mac.com/jkornhaus/filemaker/ in a few weeks.

John

[Rob P]

Thanks John for weighing in on this.

What you described is exactly what I'm experiencing with doScript. Well, either that or the script fails to execute altogether. Unfortunately I had spent a little too much time on it and had to go with conventional go to this layout now do this scripting.

I'm not exactly sure what I would be reporting to FM since I've never crossed into custom plugin development.

[Genx]

... Pausing scripts has it's own issues though, if you're in the middle of script with the window frozen and you pause that script, the window will refresh..

[Peter Wagemans]

An interesting loop, that places the called script on top of the stack. I've put this in an XML clip.

I tried this with version 10. Run this in the debugger and let it loop a few times. You'll see it switches to the called script.

Now put the debug execution pointer next to the "exit script" of the script on top of the stack.

You'll see it winds down again, coming back to the called scripts.

Rob, I know this is an old thread, but still, I read it and thought about this solution.

As for the mechanics of the DoScript, the ZippScript, the EventScript or any other script triggering plug-in there exists:

They all have to call the internal API function that FileMaker provides. When FileMaker changes the rules there, ( like in 7->8 ), there's nothing that can be done. It's the FileMaker side that decides where the script will be placed in the execution stack.

Here's the CM clip:

Let ( myScript = mFMb_DoScript ( "DoScript Loop" ; Get ( FileName ) ; Random ; "resume" ) ; 1 )