self halt in queryCommand

Hi,

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. The error log files are large, so if you want them let
me know and I will email them.

Win2k with SP1, Dolphin v4.0 P with the updated VM. No other patches
installed.

Steve

Steve

"Steve Waring" <[hidden email]> wrote in message
news:GdeT5.142701$[hidden email]...
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.

Regards

Blair

Hi Blair,

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!

Have a good weekend,
Steve