LiveCode Forums

I have a stack that uses several script only stacks. One of the stacks is set to be the behaviour of the main stack.

I have openstack handlers in several of the stacks, as well as preopenstack in the main stack.

My problem is that as I am debugging, with the pointer tool selected, sometimes scripts are running in the background and errors are reported. It is frustrating to have to go to the script and look at the errors every time. I cannot find a pattern, but I have a suspicion it might be mouseup running when I click a card with the pointer tool.

Sorry to be vague, but is there a setting that stops any scripts running when I have the pointer tool selected? Logically I would have thought that this should not happen anyway.

Kaveh

Development -> Suppress Messages should do what you need.

Fantastic. I have set it. Will report back if any problems.

So do I have to manually set this every time I go into debugging and vice versa? I was looking for a setting that suppresses messages when I have the pointer tool selected. I would have thought you don't want any messages when using that tool as you are in programming mode.

kaveh1000 wrote: ↑

Tue Jan 14, 2020 5:32 pm

So do I have to manually set this every time I go into debugging and vice versa? I was looking for a setting that suppresses messages when I have the pointer tool selected. I would have thought you don't want any messages when using that tool as you are in programming mode.

LiveCode has no "programming mode". It has a wide range of tool modes, including browse, button, field, graphic, and pointer, among others.

True, most apps don't use the pointer tool at runtime. But drawing apps do, and others that provide an environment for users to do layout tasks where taking advantage of LC's drawing tools can be quite powerful.

I just want to double check I am not doing something wrong. The behaviour I do not remember having seen before:

I have a rawkeyup handler, with an "answer tKey" statement in the first line for testing. When I am in editing mode and trying to edit the script, every key I press results in an answer dialog box. so rawkeyup is running as I am editing any part of the script, so I cannot even type.

I could suppress messages, but then I have to do that manually every time and back on again when running the stack.

Where did you put that rawKeyDown handler so that it affects everything in the message path?

Have you considered moving it to something more local to where you want it applied?

It's in one of the several stacks that are being loaded at startup. This might give a clue:

Every time I save the main stack, I notice that the Openstack handler is executed. Is that normal?

"Loaded" can mean many things. Are you using it as a library?

rawKeyDown is in one of the script only stacks that are added by saying "start using..." in the preopenstack handler of the main stack.

I might have found the problem, in that all stacks were calling the openstack of the main stack. I had a line in there that said

if the name of this stack is not... pass openstack

I had temporarily disabled it. I think ok now. Sorry for tearing my hair out in public!

No worries. We all seek a perfect path of learning, but learning happens by making mistakes and then fixing them. It's all just part of the process.

OpenStack handlers should be in the *card* script, not in the stack script.
That will also avoid the kind of error you ran into.

...and putting an answer statement in a rawKeyUp handler is pretty daft, IMO.

Hi Mark. The answer statement in rawkeydown was just a test to see when it was called, that's all.

Regarding Openstack in card, I can't work out the reason for that. Could someone explain pls?

If your stack file has only a mainstack in it you'll never need to think about it.

But if you add a substack you'll find that the mainstack's script is in the message path for all substacks in that file.

This provides a great place to put code you want used by all stacks in the file, but if you want something to be used by the mainstack only then Mark's suggestion of using the card script will ensure those handlers won't affect substacks.