LiveCode Forums.

The horror....

Save everything. Better, open a new session.

In an new stack, place a button and a field. In the button script: In the message box: Leave the debugger open. Now just play around for a while. Click on the card window. Open the inspector and try to do something. Hey, just try to click in the debugger.

Now try to quit, say, using cmd-Q. Just try...

Craig Newman

The Dictionary entry for frontScripts includes this reminder:

If the scripts in the frontScripts do not use the pass control structure to pass on the message to the next object, the target object never receives the message.

Given the very specialized nature of frontScripts, in the rare cases where they must be used the recommended best practice is to always pass any system messages trapped there.

Richard.

Did you try the test? I don't have an issue with the message hierarchy; I would never have said "horror" for something like that.

Craig

dunbarx wrote:Did you try the test?

I'm familiar with frontScripts, and the flexibility of the IDE design that allows nearly complete modification of its behavior if someone goes out of their way to take advantage of that.

What did I miss?

Richard.

Did you try the test?

Craig

Yes, but it wasn't necessary. If you go out of your way to alter global behaviors by trapping system messages without passing them, objects relying on those messages will be affected globally.

What circumstance have you encountered where the recipe you provided was needed for an app you're building? I'll bet we can come up with a good solution that doesn't require withholding system messages from controls that rely on them.

Hmmm. I should not have been playing games.

What happens is that a random number appears in the debugger, if you click in just about anywhere in it, replacing the handler text. The inspector, if you click in it, will place random numbers in the name "title" field. Clicking on any of the tabs in the message box will put a random number in the msg field. The pointer tool will be selected, and the browse tool no longer can be.

If I try to close the stack, the "save" dialog text becomes a random number (changeable at any time by continued clicking) but none of the buttons work. Force quitting LC is the only option.

You know, that sort of thing.

In one sense, since all these gadgets are stacks, I was shocked, but not awfully surprised. But it was never about my being able to manage frontScripts; I understand all you have said. I know how open and unprotected I left that stack with that frontScript. I just wondered if this morass was something anyone had ever run into before. LC 6.7.7. OS 10.9

Craig

dunbarx wrote:I just wondered if this morass was something anyone had ever run into before. LC 6.7.7. OS 10.9

I've been using all versions of the engine since 1998, and yours was the first time that particular issue has come up. Others have experimented with unpassed messagers in frontScripts, but the implications become evident pretty quickly so it's rarely attempted again.

Being so very specialized in their role, frontScripts have always been seldom used. And since the advent of behavior scripts, most older needs for frontScripts have gone away. They still serve a useful purpose, but for a very small number of practical use cases.

I will submit a bug report. There is certainly something awry.

Craig

I will submit a bug report. There is certainly something awry.

actually I can not see a bug.

your script says that is what you get.
What do you expect if you don't let the IDE sort out what to do? It relies heavily on frontScripts.

Kind regards
Bernd

Sounds like the frontScripts feature is working exactly as described. What behavior would you expect?

Richard, Bernd.

So the several IDE stacks trapping the "mouseUp" message, when they are on top, is normal. As I said, this did not seem outlandish to me, though I expected that these special stacks might be excluded. They certainly all have "mouseUp" handlers in them, I assume. If I create my own custom handler and message, and put a handler for that in front, then all is stable when I invoke it from my working stack. No problem.

But the fact that the tool palette will not allow me to select the browse tool is to be expected? And the fact that one cannot close the stack, since the "save" dialog will not process its intended functionality is also unremarkable?

If you tell me "yes" to that, then I will certainly acquiesce. It simply means that I did not appreciate how intimately connected the IDE stacks really are, in contrast to "working" stacks that I create, at least in the context of frontScripts. The frontScript is ubiquitous indeed.

Craig

If you go out of your way to alter global behaviors by trapping system messages without passing them, objects relying on those messages will be affected globally.

To avoid unexpected behaviors, just follow the general guidance to always pass any system messages handled in a frontScript.

And of course if you need a value put into a specific field from a frontScript handler it's probably a good idea to use a more specific object descriptor than "field 1".

Better still, in many cases you can skip frontScripts altogether and just use behaviors with "before <message>" and even "after <message>" handlers to accomplish many of the sorts of things frontScripts have been used for.

it's probably a good idea to use a more specific object descriptor than "field 1".

Sure. Early on I named the field and validated that it existed.

Anyway, thanks for the feedback.

Craig

If the stack has a field 1 then that's what you saw - - a random number in it. If it does not have a field 1, then the script will abort with a "no such object" error, but the IDE hides errors for its own stacks so you don't see it. Instead, the click appears to do nothing. Presumably the tool palette has no field 1, so you get the silent abort.