> Always a good way to shot myself in the foot anyway;
> With showWalkbacks=false;
> put "self halt" in a #queryCommand: method
> for example add:
> Calculator>>queryCommand: query
> self halt.
> ^super queryCommand: query
> This locks Dolphin, and Windows soon reports that it has generated errors
> and is being closed. ....
This is unfortunately what I would expect - I am afraid that the "It hurts
when I do that - Don't do that" cliche applys.
I'm assuming you've clicked on a menu in Calculator to open it, yes? Well,
your breakpoint is in a method that is going to be called repeatedly because
of the breakpoint immediately causing a debugger to open. When opening
menus, Windows goes into a very modal state (even more modal on Win9X), and
will repeatedly send the WM_INITMENUPOPUP message until it gets a reply,
which of course it won't because the debuggers are blocking it. Although not
happenning in this case (there being no toolbar), #queryCommand is also sent
at idle time when a window is marked as requiring "command validation" in
order that toolbar buttons, etc, are displayed with the correct state of
enablement. If the command state does not become "validated" then the system
will continuously attempt to validate it. Result? Meltdown.
If you use the system with walkbacks enabled, this will not happen. You will
get a second walkbacks after the first (because Windows retrys as mentioned
above) but you can just resume it and Windows will then be happy. If you
don't have walkbacks, then you never get the option of
continuing/terminating, rather than opening a debugger, and Windows keeps
retrying for ever.
Actually this is one of the reasons I think the option to disable walkbacks
is a rather daft idea. As Bill Schwab is fond of saying, be careful what you
ask for because you might get it. In an event driven system closely tied to
Windows, written in itself, and more particularly where the debugger is an
integral part of that environment, avoiding the minor inconvenience of
pressing the spacebar to enter that debugger is going to cost you in the
longer term. People asked for this option, so in a moment of madness it was
put in, but I strongly recommend not to use it. If you do, then you will not
be able to recover from any type of recursive error, and it is much easier
to bring the system down by inserting breakpoints injudiciously. The
walkback is there for a good reason, since it can be displayed safely in
many more situations than opening the full debugger. It is possible to make
even the walkbacks appear recursively, but much less likely and probably
more obvious when it happens.
BTW: A useful technique when attempting to debug code that is called
repeatedly is to insert a "conditional breakpoint". The simplest example is
to define a global variable, say X, set it to 0. Then guard the "self halt"
with a test that X is zero. If it is then increment it and halt. If not
continue. In this way you can break only the first time through. Many other
variations on the theme are of course possible.
You have sold me, I will go back to enabling walkbacks. Thanks for the idea
for the single halt, that will come in handy.
Thanks for the changes to the command routing, having the option for a
presenter to modify the route will come in very handy for a couple of UI's I
have. There does seem to be a few changes in the routing; now I have my
conditional breakpoints, I'll jump back in and start exploring!