LiveCode Forums.

Beginners section, yet again.

I actually never used a backScript before, and cannot get a simple test to work.

On a card with a button and a field, in the button script: in the stack script: Works fine...

Now if I "insert the script of this stack into back", no complaints , and "the backScripts" show the new, er, backScript.
But if I then comment out the stack script, I get an error that LC cannot find the handler "startCounter". If I restore the stack script, all works again. So why cannot LC see the handler? The message should have passed right along, no?

Me again, eh?

Craig

It should work. Can you post a sample stack?

Richard.

That's what I thought. Sure I will post the test stack, but how will that help? The test stack was new, and the only things on it were the controls I described. For giggles, I just changed the stack script a little bit to: Thinking an explicit stack reference might be the culprit, but no, it still throws an error.

Hey, you will even see the double vision I mentioned several months ago, where unless I set the "resizable" to false, I get two titlebars.

Craig

I had misread your earlier post. I thought you had a separate object being used as the backscript. Your example clarifies - thanks.

Commenting out a script will comment the script. Even if you've added it to a second place in the message path like the backScripts, frontScripts, or as a library, it's just one object with one script, so changes made to it will be reflected wherever it's used.

Backscripts are VERY useful, but rarely so when using an object already in the message path. For starters, it isn't providing anything you don't already have, and when messages are passed the script will fire twice, which is not usually what we want.

I tend to use buttons for backscripts and frontscripts, though stacks can be used too. Whichever object type you use, those are great ways to add handlers available universally for all scripts, and simplest of the objects containing those scripts are not already in the message path.

Aha.

So a backScript is dependent on the existence an "active" script in an existing object, and has no, er, objectivity of its own. It is merely duplicated in a distant part of the message path, and need not be explicitly passed from its "source" handler, if that makes sense. OK, that works, since there is no LC object, forgive me, above the stack. I guess I sort of thought it lived in or near the engine somewhere, but that cannot be.

Thanks for the clarification. I see this similarly applies to frontScripts.

Craig

Richard.

You know what threw me? The command "insert", which seemed to me to create an additional handler in some new stable environment. As said, there are no objects, ahem, beyond the stack.

Craig

dunbarx wrote: ↑

Wed Sep 09, 2020 11:54 pm

I see this similarly applies to frontScripts.

FrontScripts are super - quite literally, before anything else. Whether they are angels from heaven or the devil itself is up to how well you use 'em.

Put a bunch of handlers in a frontScript, don't pass messages, watch messages die and downstream things mysteriously never happen.

But with a pass, oh the power, handling any system message you want, even before the IDE gets it.

Behaviors are generally safer if you don't need truly global system message intervention. But if you do, frontScripts are God. Worth playing around with even if only for the joy of seeing their pervasive effects.

Hi,

I just recently started using back- & frontscripts, so I'll try to summarize:

• BackScripts are used to add functionality.
  In case of duplicate handler names still the "original handler" will respond -
  a handler in a backScript only fires if no other object anywhere handles it.
  .
• FrontScripts are used to modify existing functionality.
  In case of duplicate handler names the "frontScript handler" will respond -
  a handler in a frontScript always fires, even if other objects could do it.
  .
• Both are not copies of the used script but references to it.
  So changing the script of the object that was "inserted" will change the behavior.

So Craig's initial problem was:
- The "real" stack script had precedence anyways - it was called before the backScript.
- Had he inserted it into front instead, the commenting still had spoiled the function.

Is this correct?

Have fun!

Correct. And that's an excellent summary.

All good.

I just had never used one, and thought that, once inserted, there was some sort of independent existence of a backScript apart from the actual object that contained the "original". That is why I inadvertently disabled it when I commented out that original.

But it is indeed a duplicate, an avatar of the original, just located (OK, not going there) closer to the engine.

Craig