Rev 3.0 problems

[Peter Brigham]

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
pmbrig at gmail.com

On Mon, 15 Sep 2008 10:04:24, Paul Gabel <paulgabel at comcast.net> 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
>> pmbrig at gmail.com