Anyone using GLX2???

Jerry Daniels jerry at
Thu Mar 6 13:56:52 EST 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  
> used?

Dave, we have tried both 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 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  
version, btw.
> 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.


Jerry Daniels

Daniels & Mara, Inc.
Makers of GLX2

More information about the Use-livecode mailing list