Dolphin hangs

I've had this intermittent problem in the VC since version 2 or 3 and now
I'm seeing it in another app that I'm building.  Basically, if I use Alt-F
to activate the File menu, sometimes the VC hangs and I have to kill the
Dolphin task.  Using Alt-F has become second nature to me, so although I try
to remember not to use it, I still do ... and oftentimes regret it.  Is
anyone else having this problem?

As for the app, it's starting out as just a ShellView with a single
container to which views are added dynamically.  For illustration purposes,
the containerView has a FlowLayout and the shellView has a single menu,
File/Test, which calls #test.

test
  self view firstSubView addSubView: TextEdit new; refreshContents

When I run it, if I click on File/Test, it works fine, the TextEdits are
added one by one.  But if I try Alt-F, the system immediately hangs.  I
found that by changing the container's isControlParent to false that it
works, and that might be ok for this app, to disable tabbing in the
containerView (which is what isControlParent being false does).  Again,
anyone else have this problem and/or have a workaround?

I saw in DSDN that if you just press Alt first, and then press F, it'll
work, and indeed this is the case.  While this is good to know, I don't see
this as a workaround.  ("OK users, gather around and listen carefully:
Forget what you've learned about Windows.  Do not press ALT and F at the
same time ...")

-- Louis

Louis

You wrote in message news:a159ds$2po$[hidden email]...
> I've had this intermittent problem in the VC since version 2 or 3 and now
> I'm seeing it in another app that I'm building.  Basically, if I use Alt-F
> to activate the File menu, sometimes the VC hangs and I have to kill the
> Dolphin task.  Using Alt-F has become second nature to me, so although I
try
> to remember not to use it, I still do ... and oftentimes regret it.  Is
> anyone else having this problem?
>
> As for the app, it's starting out as just a ShellView with a single
> container to which views are added dynamically.  For illustration
purposes, see
> this as a workaround.  ("OK users, gather around and listen carefully:
> Forget what you've learned about Windows.  Do not press ALT and F at the
> same time ...")

This sounds like the "IsDialogMessage() goes into infinite loop" problem.
IsDialogMessage() is a rather strangely named Windows API call that is
responsible for performing dialog style navigation (tabbing between fields,
Alt key accelerators, etc). Apart from the fact that it isn't really a
"test" message (although it does answer true/false), its use is not limited
to dialogs. It might be better called TranslateNavigationMessage(). Anyway
following the lead of the MFC library we also use it for non-dialog shells.

Unfortunately there is a bug in the IsDialogMessage() whereby it will go
into a infinite loop in response to a keyboard navigation message when:
a) there is a nested hierarchy of windows;
b) the 'control parent' flag is turned on in parent windows; and
c) focus is lost within the active top-level window, or is set to one of the
"control parent" container views (I can't remember exactly which).

(a) is fundamental to the way Dolphin builds views from re-usable pieces.
(b) is necessary to allow navigation down through the hierarchy. Therefore
one has to avoid (c), and indeed we have to work around the
IsDialogMessage() bug in some circumstances. For one example see
CardContainer>>onTabChanged.

If you are dynamically adding views to a container with the "control parent"
flag, you may need to actively manage the keyboard focus. You could also try
overridding ShellView>>preTranslateKeyboardInput: to remove the call to
IsDialogMessage(). This will disable keyboard navigation within your view,
but it will prove whether or not this is the problem.

To investigate what is happening with the keyboard focus in your view,
either use the Spy (or Spy++) tools from the MS Win32 SDK, or add some trace
messages to Veiw>>wmSetFocus:wParam:lParam: or related methods.

Hope this helps, regards

Blair