LiveCode Forums.

I have a couple of questions regarding parameters in LiveCode.

1. Why does the default mouseUp handler's first parameter a number "1"?

2. Suppose I write the following: Why doesn't the button "test"'s script resolve the first parameter passed to an object?
Are there any cleaner workarounds without resorting to a "do" command?

Any help would be highly appreciated.
/Carl

I think it's because the first parameter of the mouseUp handler is used for defining if the mouse button clicked was left (1, default) , right (3) or middle (2). The reason why it defaults to 1 is because you didn't define what mouse button was supposedly used to click your button "test". Thus, it reverts to the default value which is 1. I haven't encountered something like this before but a workaround you can use might be global variables. Or you can just move the scripts contained in mouseUp to another custom handler and have mouseUp call that handler instead. That way, you can reference to your new custom handler via your dispatch command nstead.

Cooper,

you can get this to work if in the mouseUp handler of button "Test" you put: You provide the variable in the receiving button pWhat which you can then process. BUT this is not a good idea since if you click at button "Test" the system will send a parameter for the kind of click, a left-click is 1 for example. Now your script can not resolve the name of 1, you get an error.

The bottom line is if you send a paramter to an object the receiving object must have a variable(s) that accepts the parameter(s). Or you could look at the params function, but that is complicated in my opinion and unnecessary in such a case.

If in button test you would define a commandyou have a less ambiguous situation.
Button otherButton would then send
@ ShadowSlash
I try to avoid global variables as they are hard to handle since every open stack can access them and one tends to go into naming conventions for oneself that inadvertently declare a global in a different contexts, debugging that is a pain. I much prefer script local variables or custom properties. They are much "cleaner" since their scope is narrower or more precise. I use global variables only if I can not avoid them and up to now I did not need them in Rev. In Hypercard I had to use them and that is where I learned to very careful with them. There is a reason that Dunbarx warned against the use of them. At first they seem very handy but in the long run problems show up.

regards
Bernd

bn wrote:@ ShadowSlash
I try to avoid global variables as they are hard to handle since every open stack can access them and one tends to go into naming conventions for oneself that inadvertently declare a global in a different contexts, debugging that is a pain. I much prefer script local variables or custom properties. They are much "cleaner" since their scope is narrower or more precise. I use global variables only if I can not avoid them and up to now I did not need them in Rev. In Hypercard I had to use them and that is where I learned to very careful with them. There is a reason that Dunbarx warned against the use of them. At first they seem very handy but in the long run problems show up.

Thanks for that and I guess it's my bad. I assumed everyone else used LiveCode like I do wherein I only keep up to 1 project open at a time. That way, even if I do use globals, conflicts won't matter as I'm only using it on the same project. And as a rule I never forget the globals that I declare so I think that's another reason why I jumped to such conclusion. Thanks again for pointing that fact out.

Thank you guys for your responses. They all helped I didn't realize the numbers were the mouse button type.

It seems strange that the semantics of param(x) and declaredParam are the same, yet behave differently.

With that said, the declaredParam approach is a minor constraint that will work for my design.
BTW, in case you are curious I'm writing a framework that delegates events from other events. This is for the purpose of providing loose coupling between screen objects and building the relationship through the IDE --think Mediator design pattern.

Thanks, again. /Carl

Carl,
I don't quite understand what you are trying to do but have the hunch that you might also be interested in
executionContexts
From the dictionary:

The executionContexts is similar to a call stack, it consists of a list of contexts, one per line, with the most recent context at the end.

I don't use this but I saw recently a script where someone used it to get the "caller" of a handler in a library.
regards
Bernd

Thanks, Bernard. I'll have a look.../carl