Anyone using GLX2???
jerry at daniels-mara.com
Thu Mar 6 12:56:52 CST 2008
On Mar 6, 2008, at 12:01 PM, Dave wrote:
> t may have fixed bugs in the RunRev Script Editor, but wouldn't it
> have been better to fix the problem instead of having two parallel
> ways of setting a breakpoint, especially since the way in which the
> Standard Script Editor works is in line with 99% of debuggers I have
Dave, we have tried both ways...red dots or not. We opted for using
the command "breakpoint" and it is very reliable. That said, there's a
lot i'd like to do with the debugger...all in good time. I'm more
convinced that a standalone app as debugger would be very
helpful...one you could use to debug stacks running in the Rev IDE or
your own standalone app. This is very possible and is our hope going
forward. This would not give you the same experience as the Rev IDE
script editor/debugger as one experience, however.
There are several areas in which the operation of the IDE and the UI
come into conflict with a debugger. We look to the standalone debugger
as a good answer to some of those problems. in the mean time, we do
have script snapshot which Trevor invented for us and it is great at
tracking variable values in "snapshots" and letting you sift through
them after a script has run. Script snapshots get set just like debug
breakpoints in GLX2. You only need to switch from Debug Mode to Script
Snapshot mode via the GLX2 Script menu (from GLX2 menubar).
We don't offer the exact same experience as the Rev IDE script editor
and debugger. That means some learning curve, but much opportunity to
develop faster, better, cheaper. Tabs make a big difference in what
makes sense and what doesn't in surprising ways. Using GLX2 is usually
done with a small leap of faith and a little advice here and there
from users on the GLX2 support site. I'll get our support team (my
son, Joe) to make sure you get signed up, as we have gotten no email
requests from you to date.
> If there are two ways of doing it then there should also be some way
> to clear all the RunRev breakpoints from the user stacks. The way it
> is now, I have a number RunRev breakpoints set that DO NOT cause the
> RunRev debugger to stop (and AFAICT are not even visible as
> breakpoints in the Standard Editor), but do cause GLX2 to stop. When
> it does stop the statement in question is not displayed in bold, and
> editing the file before running does not show the statement in bold.
> If I click on the line then it changes to bold (even tho it's
> stopped on a breakpoint). If I hit it again, it goes back to normal
> and if I run it doesn't stop next time that statement is run.
> However, the next time the stack is opened, the same thing happens.
> I found the documentation on the site of minimal help. Is there a
> PDF with things laid out in a more ordered fashion and where I can
> search and easily jump around. The web site is more an advertising
> opportunity than what I'd call "Documentation".
In the Help menu on GLX2 there are some lessons, too. The stuff on the
main GLX2 web site IS promotional, but that's easily filtered, i would
think. Hard to keep enthusiasm out of one's voice sometimes. hehehe.
> One other very annoying and confusing thing is the way in which the
> Script Editor is opened when RunRev is launched. While its great to
> not to have to go to the bother of opening the Scripts of all the
> objects you were working on, it is very confusing to have the Menu
> switched at start up. I think it would be better to open the Script
> window but not to select as the front window, therefore allowing the
> expected menubar to be shown.
I think the release version does this, but the latest beta does not.
We do have a beta track of updates for those wanting to try the latest
and greatest at all times. You can always go back to the release
> Except for the breakpoint the thing, the editor is very good though
> and a great improvement over the standard version. I can't help
> thinking newbies that have used the standard RunRev for a little
> while would become confused very quickly though, especially without
> a document describing exactly what GLX2 changes and how this affect
> the rest of the system.
So far we have opted to putting most of our resources into continued
development at some expense to mammoth documentation. I hope you'll
bear with us and give a new approach and environment a chance. We
appreciate your business and continued use of the product, of course.
Daniels & Mara, Inc.
Makers of GLX2
More information about the use-livecode