On Fri, 12 Sep 2008 19:12:01, Ken Ray <[EMAIL PROTECTED]> wrote:
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?
Peter, I'm not seeing this... I created a stack, added a button,
set the
script to:
on mouseUp
answer "Hello"
end mouseUp
and then Command-Option-clicked the button with the browse tool... the
script editor opened, but no answer box.
Is it possible it's a front/backscript or library that's being
triggered?
Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
Well, my personal frontscript only has handlers for suspend, resume,
and controlkeydown messages, there are no backscripts, and I haven't
tweaked the rev IDE scripts at all. The only stack in use is
revAltLib. I'm mystified. Anyway, does anyone know where the IDE
handles the decision to trap or pass mouseup when opening the script
editor?
Peter M. Brigham
[EMAIL PROTECTED]
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
