Problem with openStack

[Jozwolf]

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.

[dunbarx]

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

[Jozwolf]

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

[Simon]

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.

[[-hh]]

..........

[Simon]

Excellent Hermann!

Simon

[Jozwolf]

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

[dunbarx]

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

[[-hh]]

..........

[Jozwolf]

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

[dunbarx]

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

[Jozwolf]

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

It makes me wonder if the diagnosis is correct!

All the best,

Jim

[dunbarx]

Jim.

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

Code: Select all

on openStack
   send "mouseUp" to btn "bbb" --btn has a "mouseUp" handler
end openStack[/code

But it took a lot of fooling around to get it to work, and there is no doubt that it did not work just 10 minutes ago. And when I say fooling around, I mean just playing with the message watcher, trying different handler gadgets, trying a card script, etc. But the end result is a bare-bones stack with just two scripts Tried this in v5.5 as well. This works in a new session.

There have always been gremlins in LC, just as there were in HC. It is unsettling...

Craig

[jacque]

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:

Code: Select all

on preOpenCard -- in the first card of the mainstack
  -- do whatever here
  send "setTool" to me in 1 tick
end preOpenCard

on setTool
 choose browse tool
end setTool

[dunbarx]

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