This content has been marked as final. Show 7 replies
> How can I call (for example) to the button2 to execute the handler2 click
> on button1?
Check the docs for 'sendSprite' and 'sendAllSprites'
> I have two buttons each one have a diferent handler.
> button1 handler1
> button2 handler2
> How can I call (for example) to the button2 to execute the handler2
> on button1?
You can also just call a handler on another sprite directly. Like, say
you've got the following code on sprite 2:
on mouseUp me
<do some stuff>
On sprite 1, you can activate sprite 2's code just by doing the following:
on mouseUp me
This simulates a mouseUp event on the 2nd sprite, causing it to <do some
stuff> just as if you'd clicked on sprite 2 directly. You can do the same
with custom handlers. Any handler on a sprite can be called in this way.
see if this is what you want
if so go here and save "target as" on the link to download and get the DIR file for the source (link with the bullet point)
let me know if it helps
I never heard of doing it that way .....but it works
so Anne, for that last example, it looks like it can go either way
-- sendsprite (1, #beepsound)--activates the handler "beepsound" that belongs to a beep behavior attached to sprite 1
> I never heard of doing it that way .....but it works
> pretty cool
Yeah, I think the method I use is newer code, in that you couldn't do it in
earlier versions. Back before they added Dot Syntax, I think sendSprite was
the only way to do this. I like my method though, as it's usually less
typing, and easier to read, too.
> I like my method though, as it's usually less
> typing, and easier to read, too.
It will provoke an error if the handler you're trying to call doesn't
exist within the scope of the sprite you're calling, whereas
> It will provoke an error if the handler you're trying to call doesn't
> exist within the scope of the sprite you're calling, whereas
> 'sendSprite' won't
Well, that's true. But whenever I have a need to use this trick, the sprite
being called pretty much always has the handler on it, so I don't usually
run into that. I can see where you'd maybe need to sendSprite instead, like
if you were choosing a sprite at random to make it do something, and some
sprites did and did not have the handler you were calling or something, but
it seems to me it's just more efficient to make sure you're only sending
commands to sprites that have the appropriate handler, rather than send out
a signal and hope that something can understand it.
Also easier to debug. If you send to the wrong sprite in my method, you get
a nice error message telling you so. Send to the wrong sprite with a
sendSprite, and - well, nothing happens, so it's sometimes harder to figure
out what exactly happened (or didn't happen). Error messages aren't always