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 | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
