Re: Rev 3.0 problems
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 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
Re: Rev 3.0 problems
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? 1) In the new script editor, right-clicking/control-clicking on a function or handler hame is supposed to open a script editor panel for that function/handler, whichever object's script it might be in. This works for me about 20% of the time. I haven't pinned down a pattern to it, if there is one. Most of the time I get the generic Go to definition/Find in Docs/Set breakpoint/cut/copy/paste popup menu, the way I would if I right-clicked on any random word in the script. 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? BTW, Jacques, I have loved using your script editor shortcuts and I patched your frontscript so it works for me in the new script editor. Don't know if you want to release a 3.0 update of this for others... 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 ___ 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
Re: Rev 3.0 problems
Peter, You might want to try a nifty tool I've worked on to help make 3.0's script editor work better for me. altXray is a plugin for Rev 3.0. It works best with altPlugin Toolbar. http://www.altuit.com/webs/altuit2/altPluginCover/About.htm It helps Rev in a number of ways: Outside Script Editor - Shows the name of the control the mouse is hovering over - Ctrl-Alt edits the script of the control the mouse is hovering over - Shift-Ctrl-Alt edits the properties of the control the mouse is hovering over - Ctrl-Alt over the stack Titlebar edits the script of the stack - Ctrl-Alt over the very right of the Titlebar edits the script of the card Inside Script Editor - Right click on function or handler name in a script jumps to the function or handler within the message hierarchy-- opening up script tabs if necessary. This is very useful if you use script libraries. It's pretty simple, does NOT change anything in Rev and can be turned on or off by clicking a checkbox in the small palette. Option clicking altXray puts it (floating) in the main Rev toolbar (WinXP) or just docs in on Mac. This has not yet been tested much on a Mac, so feedback would be helpful. To install is, just type into the message box: go URL http://www.gadgetplugins.com/altplugins/altXray.rev; then immediately save to your altPlugins folder. Next refresh your altplugins toolbar (click the small blue arrow on the top) If you don't have the altplugins toolbar, you can put it in the regular plugins menu, but make sure it opens as a palette (or alt-click it after opening it, which will also palette it.) Like most all of our plugins, this is not a *supported* plugin. Use at your own risk! ___ 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
Re: Rev 3.0 problems
On Sat, 13 Sep 2008 17:07:24, J. Landman Gay [EMAIL PROTECTED] wrote: Peter Brigham wrote: 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? Since you mentioned you're using the frontscript I made, check that one too. There's a handler in there to catch command-option-click. The one I'm using doesn't pass mouseup, but if you edited it, yours might. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com I had extracted your controlkeydown handler and incorporated it into my own frontscript -- I use control-shift-keydown for all my text shortcuts so I made your routines respond to control-shift-space etc. I have no mouseup or mousedown handlers in my frontscript at all. Good idea though. It sounds as though no one yet has delved into this aspect of the 3.0 IDE enough to know where it would be passing the mouseup If anyone comes across this, I'd appreciate knowing about it 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
Re: Rev 3.0 problems
On Sun, 14 Sep 2008 01:09:18, Chipp Walters [EMAIL PROTECTED] wrote Peter, You might want to try a nifty tool I've worked on to help make 3.0's script editor work better for me. altXray is a plugin for Rev 3.0. It works best with altPlugin Toolbar. http://www.altuit.com/webs/altuit2/altPluginCover/About.htm Thanks, Chipp. I actually downloaded it last week and have been trying it out. It's very handy -- I just have to get used to waiting to hold down my modifier keys until the mouse is actually over the control I'm thinking of. I found I have been in the habit of pressing command-option while moving the mouse to the control, and with AltXray that gives me the script of whatever random field or background image I happen to pass over I use your Archive plugin all the time -- being able to back up easily has saved my ass a few times. I modified your script so that the file names it uses look like: PPdata.rev (08-08-29)01 PPdata.rev (08-09-04)01 PPdata.rev (08-09-11)01 PPdata.rev (08-09-14)01 PPdata.rev (08-09-14)02 -- that way the files appear in the finder in chronological order. What I do is archive whenever I make a modification (most of the time I remember), then clean out the archive file every now and then by moving the older archives to trash and keeping the most recent dozen or so, then I move the oldest of that bunch to a folder called breadcrumbs so I have a very long-term sampling of my versions over time. Thanks for both plugins, they're terrific. 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
Re: Rev 3.0 problems
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
Re: Rev 3.0 problems
Peter Brigham wrote: 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? Since you mentioned you're using the frontscript I made, check that one too. There's a handler in there to catch command-option-click. The one I'm using doesn't pass mouseup, but if you edited it, yours might. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ 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
Rev 3.0 problems
I do like 3.0 a lot, but there are two things that are annoying to me. Has anyone else noticed these? 1) In the new script editor, right-clicking/control-clicking on a function or handler hame is supposed to open a script editor panel for that function/handler, whichever object's script it might be in. This works for me about 20% of the time. I haven't pinned down a pattern to it, if there is one. Most of the time I get the generic Go to definition/Find in Docs/Set breakpoint/cut/copy/paste popup menu, the way I would if I right-clicked on any random word in the script. 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? BTW, Jacques, I have loved using your script editor shortcuts and I patched your frontscript so it works for me in the new script editor. Don't know if you want to release a 3.0 update of this for others... 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
Re: Rev 3.0 problems
On 13 Sep 2008, at 01:25, Peter Brigham wrote: 1) In the new script editor, right-clicking/control-clicking on a function or handler hame is supposed to open a script editor panel for that function/handler ... I never used this, and when I tried it right now, it never seems to do that, I always get the context menu popup, can you explain this with a bit more details? 2) ... Now, it opens the script editor but also passes the mouseup ... Whether yes or no to that question, any pointers on how I can block the pass mouseup in the rev scripts? ... I'd say yes or no is an issue, as I often use this, and it never just passes mouseUp's on for me (though it did in some betas for 2.9), maybe there's some plugin installed, or an edit you made to the ide that causes this? sorry for not helping :( Bjoernke -- official ChatRev page: http://bjoernke.com/runrev/chatrev.php Chat with other RunRev developers: go stack URL http://bjoernke.com/stacks/chatrev/chatrev1.3b3.rev; ___ 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
Re: Rev 3.0 problems
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/ ___ 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
Re: Rev 3.0 problems
Peter Brigham wrote: BTW, Jacques, I have loved using your script editor shortcuts and I patched your frontscript so it works for me in the new script editor. Don't know if you want to release a 3.0 update of this for others... I can't even remember if I sent it to anyone else. :) If anyone is using it and wants an update, just drop me a line in email. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ 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
