Constellation's Great, But the Rev IDE Doesn't Suck

[J. Landman Gay]

David Burgun wrote:
>> On Oct 18, 2005, at 8:36 AM, David Burgun wrote:
>>
>>> I mean I've been using RunRev now for about 2 years, but still:
>>>
>>> 1.  The debugger refuses to obey breakpoints.
>>
>> I see this sporadically as well. I wish I could find a pattern as then 
>> I'm sure RunRev could and would fix it.
> 
> 
> I have even had it refuse to breakpoint when I have inserted a 
> breakpoint statement. I reckon the reason is because of a scope problem, 
> since often stepping up to the place where a handler is called and then 
> stepping into the handler causes it to respond to breakpoint from then 
> on. The problem is that it is not always easy to do this, since some 
> handlers are called directly by RunRev and then is no calling statement 
> to step from.

I've written about this problem before, and I'm not sure there is an 
easy solution. I use both MetaCard and Revolution IDEs, and they respond 
differently to the same situation, which you correctly identify as a 
scope issue. But first, a definition of the problem:

Breakpoints are not always acknowledged if an error occurs in a script 
or handler that is not the one containing the breakpoint.

At least, I think that's it. For example, I was using a library that had 
been inserted into the message hierarchy. It contained an error. 
Breakpoints inserted into handlers that called this library would not break.

Mark Waddingham partially explained the reason to me -- it has to do 
with double error conditions in the debugger. When double errors occur, 
the IDE has two choices: loop recursively, or exit. Revolution chooses 
to exit. MetaCard, on the other hand, loops forever -- which means I 
must force-quit and restart the application (usually losing my work.) 
Given this choice, I think exiting is a better solution.

Ideally the engine would resolve the recursion and offer some kind of 
error information. I don't know enough about the debugger to know if 
this is possible. Commenting out the source of the error in my library 
script did cause breakpoints to resume working. The problem, of course, 
is that it is difficult to find the error in the first place because 
there is no information given about it. Locating the source of conflict 
is an exercise in patience.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com