Anyone using GLX2???

[Dave]

Hi,

> We use the command "breakpoint" in the code to indicate a  
> breakpoint in GLX2. This has solved many other problems in the  
> process...like constantly migrating red dots and performance  
> problems on large scripts in the Rev script editor.

It 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?

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".

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.

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.

All the Best
Dave

On 6 Mar 2008, at 15:53, Jerry Daniels wrote:

> Dave,
>
> We use the command "breakpoint" in the code to indicate a  
> breakpoint in GLX2. This has solved many other problems in the  
> process...like constantly migrating red dots and performance  
> problems on large scripts in the Rev script editor.
>
> Once in the GLX2 debugger, you can easily set additional  
> breakpoints by clicking on any link whereupon it will become bold  
> and stop the debugger when encountered.
>
> There is significant documentation on our support site and on our  
> web site indicated below. There is a support site, but you have to  
> sign up for it. We didn't get any request for support sign-up from  
> you, but I will check into this and make sure you're on board.
>
> Sorry for your frustrations, but we can get it all sorted out for you.
>
> Best,
>
> Jerry Daniels
>
> Daniels & Mara, Inc.
> Makers of GLX2
> http://www.daniels-mara.com/glx2
>
>
>
>
> On Mar 6, 2008, at 8:33 AM, Dave wrote:
>
>> Hi,
>>
>> Has anyone used GLX2? I started using it a couple of days ago and  
>> have had nothing but problems on the debugging side and with no  
>> decent documentation I can find and no support it's hard to know  
>> how it is *supposed* to work rather than what I am seeing.
>>
>> 1.  I can find no way to insert or remove a breakpoint without  
>> aborting the current debugging session. The "Breakpoint" menu item  
>> just inserts a "breakpoint" statement into the source code. It  
>> says clicking on it will disable/enable it, but this doesn't seem  
>> to have any effect, it always breaks regardless of if it's  
>> highlighted or not. The only way I can find to remove the  
>> breakpoint is to edit the source code and physically delete the  
>> "breakpoint" statement, which kill the current session.
>>
>> 2. Old breakpoints added with the standard RunRev IDE Script  
>> Editor (the red dot at the left of the statement) triggers the  
>> GLX2 Debugger and I can find no way to get rid of them. The  
>> amusing thing here is that the standard debugger ignores them, so  
>> you can't tell where they are until GLX2 finds them and GLX2 can't  
>> remove them!
>>
>> 3. The editor or debugger seems to lose track of which is the  
>> latest version of the Script and so the code that is run is not  
>> the same as the code displayed in the Source Window.
>>
>> I've sent two emails a week apart asking to be registered for  
>> support but no reply.
>>
>> These issues are making it unusable and I'm about to uninstall it,  
>> which is a real shame since the editor is miles better than the  
>> standard IDE version.
>>
>> All the Best
>> Dave
>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>