Well, if you have an "if the optionkey is down" line in the script
then of course, if the mouseup is passed by the IDE, this is the part
of the handler that will be triggered (you're holding the command and
option keys down). But this means that the IDE passes the mouseup --
if not, then nothing in your handler would be triggered at all. Try
it with a new button with the script
on mouseup
put "shiftkey is" && the shiftkey & cr & \
"controlkey is" && the controlkey & cr & \
"optionkey is" && the optionkey & cr & \
"commandkey is" && the commandkey
wait 3 seconds
hide msg
end mouseup
On my system I get the messagebox popping up with the accurate state
of the modifier keys in all cases; specifically, when I do a command-
option-click the script opens and I also get the messagebox notifying
me that the option and command keys are "down." Pre-3.0 if the
commandkey were down, a mouseup handler would not be triggered. If
you get the same behavior with the above script, that would confirm
that in your setup, too, the IDE passes the mouseup. What is your
setup? Mine is Mac iBook G4, OSX 10.4.1, Studio 3.0.0 build 750. We
may be narrowing in on a bug report....
Peter M. Brigham
[EMAIL PROTECTED]
On Mon, 15 Sep 2008 10:04:24, Paul Gabel <[EMAIL PROTECTED]> wrote
Hi Peter:
By any chance, do you have an "if the optionKey is down ..." line in
your button's script? I've noticed that in 2.9, option-command-click
on a button (with this line in the button's script) wouldn't trigger
the underlying optionKey procedure, but in 3.0 (irritatingly) it does.
Paul Gabel
---------------
On Sep 12, 2008, at 4:25 PM, Peter Brigham wrote:
I do like 3.0 a lot, but there are two things that are annoying to
me. Has anyone else noticed these?
... snip ...
2) More annoyingly, it used to be in versions <= 2.9 that command-
option[alt]-clicking (in the IDE) on a button/locked field/graphic
while using the browse tool used to open the script editor for that
control. Now, it opens the script editor but also passes the mouseup
-- so trying to do this on a button opens the script but then
triggers the button action. This is especially problematic when I
then get a "cannot save script while executing" alert after editing
and trying to save the script. For now, I have to change to the edit
tool before command-option-clicking on a button to edit its script.
I tried to look into the Rev 3.0 frontscripts to find out where and
how the mouseup message is being passed but I can't find the place
where I could tweak the rev scripts to patch this. Anyone else see
this behavior? Whether yes or no to that question, any pointers on
how I can block the "pass mouseup" in the rev scripts?
... snip ...
Peter M. Brigham
[EMAIL PROTECTED]
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
