LiveCode Forums.

Hi everyone. A most mysterious development. Can anyone help????

In the last 24 hours I have encountered the following LC script problem. Example:

In the mainstack script
On openStack
answer "Hi" with "Yes" or "No"
send "mouseUp" to button "Test" of card id 1002
end openStack

Button "Test" of card id 1002 with script
on mouseUp
ask "Got the mouseUp"
end mouseUp

Works fine if I send an "openStack" to mainstack using a button, but fails to activate Button "Test" if I allow mainstack to open by re-launching the script - which is what I want.

Works fine on re-launch if I have commented out the answer command, but I need it.

Fails even if I try a work around by creating a new button to do the "answer" command, triggered by sending a mouseUp to it from the mainstack script.

Oddly I had this working properly 48 hours ago and it is still working in my compiled standalone! Something has happened.....!X@#

Can anyone please help? I am not a regular programmer so I may have something misunderstood. But I have tried everything I could think of including replacing send with dispatch, but with continuing failure.

Hi.

Not sure what you mean by:

but fails to activate Button "Test" if I allow mainstack to open by re-launching the script - which is what I want.

But if I open the stack I get both dialogs to fire, just as they should.

If you make a new mainstack, like I did, and put these handlers into the appropriate scripts, do you not get the result you want?

Craig Newman

Wow - thanks for the quick reply Craig. I did make a completely new stack with those two handlers and saved it. It is when I quit livecode and then re-launch the script by double clicking on it, thus re-launching livecode and by that means opening the stack that I find that the mainstack script will not successfully pass mouseUp to the Test button.

I am bemused because I had it working early yesterday. But now however I dress it up I get the same fail.

Let me know if you are opening the mainstack by re-launching the script as described above.

Warm good wishes.

Jim

Hi Jim,

Happy Holidays Craig.

I did get the error described using a new stack (weird).
Only if you hit the button then run openStack in the message box does it work.

Placing the "send" in another btn works but not running the send from the message box.

Simon
Edit: The above happens if you close the IDE then open the stack. Seems once the btn has been recognized it sticks in the IDE.

..........

Excellent Hermann!

Simon

Brilliant! Works in both the test script and the script I am working on.

Thanks a million Hermann and have a well-deserved 2014!

Thanks to Craig and Simon too for getting us here.

Warm good wishes,

Jim

All.

It could be, and I have not tried this from a new session, which is what I think you are all talking about, that the card has not loaded quite yet when the openstack handler runs. This may be why the card control is not receiving the message. The "wait" probably allows all that to come through. I tried this in the same session, and maybe the stack was still in memory. It needs to be confirmed that if the stack is purged from memory within a session if the same issue arises.

Craig

..........

Hi Craig,
Would it not be the case that if we forced the script to wait, say 1 sec, before sending the openStack command to the mainstack on launching the script (and LC) that it should give adequate time for the card to load?

I tried that by replacing

send "choose browse tool" to me in 1 tick (as suggested by Hermann)

with

wait 1 second

The Test button still failed to receive/act on "mouseUp" in the case of the latter command, but of course worked with the former command (as suggested by Hermann).

Not sure if this helps,

All the best,

Jim

Jim.

Your thinking is spot on. Try again with 2 seconds.

Although it seems like the placement of the handler into an openStack script should cover all bases, since it fires when the stack opens and is at a high level, the mechanics of assembling all the components of that stack seem indeed to take some time. If we think about this at a deeper level, it is reasonable to say: "if I want to send a message to a card control, I ought to place the handler that generates that message at the card level".

Now this is all hindsight, though I have tripped over this sort of thing before. My memory, you see...

Anyway, that is why I cavalierly tested with a stack saved in a single session. That stack was already in memory, and of course so was the card in question. When I set the properties to purge the stack, or when starting a new session, the issue that Jim raised came up right away. Sloppy on my part. The lesson is that LC has feelings just like the rest of us, and we have to respect them.

Craig

It didn't even work with a 60 second wait!

It makes me wonder if the diagnosis is correct!

All the best,

Jim

Jim.

Hmmm. This is odd. I now have a stack that works without any wait interval, with nothing but this in the stack script:

The IDE mostly takes over the message queue while it starts up. It executes its own handlers and then passes each message to your stack. Once everything is loaded, it does some last cleanup, like forcing the tool to the pointer tool. It is impossible to set the browse tool during a startup sequence because the last thing the IDE does is reset it. That is also why a "wait" command won't work -- the handler will pause for the wait, then everything continues and the IDE finally sets the tool at the end.

The only way I've found to set the tool during startup is to "send" the message so that it executes after the IDE is done with the startup sequence. It doesn't work to send the "choose" command directly, or at least I haven't been able to get it to work, so I create a short handler that sets the tool and I call that:

Jacque.

All works fine in "preOpenCard" or "openCard" handlers, either in stack or card scripts,. The oddness is in an "openStack" handler in the stack script. I cannot get this to fail any longer, and I have tried a few new stacks from scratch. But it did fail, both reliably and intermittently (!) over the last few days.

It got better.

The intent was to send a message to a button. The business of choosing a tool sounds similar, though. But if, as you say, that selection is managed by the IDE on startup, it may not exactly fall into the same morass this thing seems to.

Craig