Unable to send mouseup message from openStack handler

[jbinder]

Hi,

I'm having trouble getting a mouseup message sent to a button from an OpenStack script. This is the script command:

on openStack
send mouseup to btn "Load" of cd 1 of this stack
end openStack

Seems very straightforward to me, but when I open the stack, nothing happens. I know the mouseup handler in btn "Load" is working fine, so why is it not getting the message when the stack opens?

I've tried several variations, nothing works. I've tried doing many other things with the openStack script (such as opening and reading from a file), and they all work fine. I just can't seem to get it to send a message to another object.

Thanks for any advice.

[dunbarx]

Hi.

No reason at all this does not work.

Are you sure you are getting back to your stack by opening it, and not just by resuming it?

Otherwise there is something else going on, because this cannot fail.

Craig Newman

[Klaus]

Hi jbinder,

1. welcome to the forum

2. try one of these, one of this SHOULD work!
If that does not work, then Craig is right, something else must be going on...
...
send "mouseup" to btn "Load" of cd 1 of this stack
## Always use quotes around handlernames that you send!
...
send "mouseup" to btn "Load" of cd 1 of this stack in 1
## A little delayed
...
send "mouseup" to btn "Load" of cd 1 of stack "explicit name of stack here"
...
send "mouseup" to btn "Load" of cd 1 of stack "explicit name of stack here" in 1
...
You could also put this handler into the script of cd 1 of that stack!
That way you can avoid that substacks with NO "openstack" script will execute this one, too!

Or "outsource" the "mouseup" handler to the stack script, give it a name and "trigger" it with
"mouseup" in the button and directly in the openstack handler:

Code: Select all

command the_one_in_the_mouseup_handler
   ### your stuff here
   ###...
end the_one_in_the_mouseup_handler

Then:

Code: Select all

on mouseup
  the_one_in_the_mouseup_handler
end mouseup

And:

Code: Select all

on openstack
  the_one_in_the_mouseup_handler
end openstack

You get the picture


Best

Klaus

[jbinder]

Thanks for the replies. Still no luck.

To clarify, this is a single stack with no substacks.

In response to Craig, I am testing the script by completely quitting LiveCode and restarting.

I tried all of these suggestions by Klaus:
...
send "mouseup" to btn "Load" of cd 1 of this stack
## Always use quotes around handlernames that you send!
...
send "mouseup" to btn "Load" of cd 1 of this stack in 1
## A little delayed
...
send "mouseup" to btn "Load" of cd 1 of stack "explicit name of stack here"
...
send "mouseup" to btn "Load" of cd 1 of stack "explicit name of stack here" in 1
...

Unfortunately, none made any difference.

Weird, huh?

I can do the workarounds suggested by Klaus, or just put the contents of the "Load" btn script into the openStack script, but I'm puzzled why the original script doesn't do what it's supposed to.

Jeff

[dunbarx]

Jeff.

This is very odd. If I make a new mainStack, and place a single button in it, with some cute handler like:

on mouseUp
put random(99)
end mouseUp

and then put, verbatim, your handler in the stack script (yours is in the stack script, right?), I get random numbers in msg every time I open the stack.

Do you?

Craig Newman

[sturgis]

If you go into your scripts (the button and the opencard) make a little bit of nothing change and apply the changes, does it start working?

[Mark]

Hi,

Which version of LiveCode and which operating system do you use? Does the stack appear on screen or do you have to open it again using the File menu?

Kind regards,

Mark

[Randy Hengst]

I've been able to duplicate the problem that jbinder described.

I made a new stack and put this script in the stack script
on openStack
answer "Open Stack"
send "mouseUp" to button "Load" of card 1 of this stack
end openStack


I made one button called "Load" and placed this script in the button script.
on mouseUp
answer "Button Opened"
end mouseUp

When I open the stack with LC not running... only the stack answer call is sent.
When I open the stack with LC running and the Browse Tool selected, both the stack answer call and the button answer call are sent.
When I open the stack with LC running and the Edit Tool selected, only the stack answer call is sent.

Can anyone duplicate what I described?

be well,
randy

[dunbarx]

Yep. I see this too. Even writing:

send "mouseUp" to button "Load" of card 1 of this stack in 2 milliseconds
or
wait 1 millisec with messages

does not help, and these used to be a reliable workarounds.

Why would the tool matter?

Craig Newman

[jacque]

Why would the tool matter?

Probably the IDE is blocking some messages on startup, and behaves differently when opening a stack in browse or edit mode. I'm guessing the behavior would be consistent in a standalone. It used to be you could start up the engine without the IDE running if you command-double-clicked a stack (which would provide a good test) but I haven't tried that in years and I don't know if it still works.

[sturgis]

with the edit tool selected, sending mouseup to the button from the msg box doesn't work. With browse it does. My guess is that the ide is catching it, yet it seems like if that were the case the button would select.

However, this points to part of the answer. If you change the script in the stack to this:

Code: Select all

on openStack
   answer "Open Stack"
   send "browseTool" to me in 100 milliseconds
   send "mouseUp" to button "Load" of card 1 of this stack  in 200  millisecond
end openStack

command browseTool
   choose browse tool
end browseTool

EDIT: also noticed that on my machine when starting with a stack double click, the rev graphic in the answer dialog is conspicuously missing. But with the above change, both dialogs show.

Both fire as they should. Times are random, probably don't need to have that much delay.

[dunbarx]

These sequences of messages within the IDE, especially on startup and upon opening stacks, show just how "live" LiveCode is. It is struggling with its own internal bookkeeping and event management, just as we are. It is disconcerting, though, since users are accustomed to rigid behavior in software. I am not discounting quirks and bugs, but the LC IDE seems to juggle the handling of these sorts of user code in a valiant struggle, mistiming and sometimes missing entirely, beyond what, say, Excel must deal with, a more drab and "ordinary" program.

This is endearing in a way, if you appreciate that the LC must accommodate its own scripted world, as we do, and share its inexact procedural meanderings.

Craig Newman