If an item is added to one of the top-level sub menus (e.g. a history list item on the file menu), there can be trouble

Description

Reported by John D. Yarrow; checked by Hallvard Vassbotn

If this is done while a child is maximized, the system menu, minimize, maximize/restore, and close gadgets are deleted on that child window.
Cause:
The VCL code that implements TMenuItem.Insert causes the entire menu to be rebuilt. If the addition is a direct-submenu item of a top-level menu, it re-builds the entire menu bar. When it does this, it deletes all menu items. If a child is maximized at the time, the 4 gadgets are a part of that menu bar, and are deleted as well.
OS's Affected:
All versions of Windows using the new GUI (Windows 95, NT 4.0).

Comment from checker:
I can confirm this bug-report. It still happens in Delphi 2.01 and Delphi 3.01. The code for TMenuItem.RebuildHandle is still the same. It deletes all items in the native Windows API level menu object before copying the Delphi level MenuItem objects into the image kept by the Windows API. The deletion also removes the system menu in the cases described below, but these are not restored (there are no corresponding Delphi objects).
It is interesting to see that the Delphi IDE itself uses the workaround of having a separate level for the dynamic list (File|Reopen).

Solution / workaround

Those wishing to dynamically add menu items (i.e. for a file history list) to an MDI application should either:

1. Build the history list off a File|ReOpen sub-menu like in the IDE (the nesting prevents the main menu tree from being re-built).
2. Either prevent the maximizing of child windows or ensure that new menu items aren't added while a child is maximized

Menu options and toolbar buttons are not always grayed like they should be

Description

Under windows 95. Create a new MDI application. Run the application. Using "File:New" create 2 or more child windows. Minimize each child using their minimize button. Now close each child using their close (x) button. What happens is that the menu options and toolbar buttons are NOT grayed like they should be. If you open just 1 child, minimize it, and close it the buttons will be grayed just like they should be. If you use 'Close' from the child's system menu the buttons are also grayed like they should be (no matter how many children you create).

Minimized MDI child windows stop responding to keyboard input after a modal form has been used

Description

Reported by Jo Van Geite; checked, edited and worked around by Chris Rankin

Reproducing the problem:

• Create an MDI application
• Create several child windows and minimise them all.
• Display a Delphi form using ShowModal.
• Close the modal form.

NOW - THE BUG: none of the minimised child windows will accept keyboard input, although they all accept mouse input. If you try to close one using CTRL-F4, or shift between them using CTRL-F6 or CTRL-TAB then nothing happens. However you can click on them, and once you restore a child it behaves normally. And if ONE child starts behaving normally then they ALL accept keyboard input, PROVIDED you keep at least one normal child window hanging around. If you kill all the normal children then any remaining children (which existed before the call to ShowModal and which were never Restored or Maximised) will stop accepting keyboard input again.
It's Weird!!!
I have managed to determine that Windows considers all of the "naughty children" to be Enabled, so no help there.

Note from checker: in fact, you can reproduce this bug without using ShowModal and a Delphi form. Just create two MDI children, minimise them and then close the child you minimised SECOND. You cannot now kill the remaining child using CTRL-F4.

Solution / workaround

The root of this problem is that Screen.ActiveForm is only set when a control on a form receives focus. In MDI applications, the active form is a child window. Therefore Screen.ActiveForm is set to Nil if you kill the active form while all other child windows are minimised, since no other child can become the active form until it is either restored or maximised. The final piece of this bug is that Delphi (or more accurately TApplication.IsMDIMsg) will only call the TranslateMDISysAccel() API if Screen.ActiveForm is assigned.

I have found two possible workarounds; one involves "hotwiring" the TApplication.IsMDIMsg() function so that MDI children still receive messages when Screen.ActiveForm is Nil:

  if (MainForm <> nil) and (MainForm.FormStyle = fsMDIForm) and
    ((Screen.ActiveForm = nil) or
     (Screen.ActiveForm.FormStyle = fsMDIChild)) then

However, this is unacceptable in Delphi 3 if you need to use packages. A better solution is to intercept the WM_NCACTIVATE message in the MDI child forms:

type
  TMDIChildForm = class(TForm)
    ...
  public
    ...
    procedure WMNCActivate(var Msg: TWMNCActivate); message WM_NCACTIVATE;
  end;

procedure TMDIChildForm.WMNCActivate(var Msg: TWMNCActivate);
begin
  if Msg.Active and IsIconic(Handle) and Assigned(ActiveControl) then
    SetFocusedControl(ActiveControl);
  inherited
end;

Both these solutions fix the demonstration MDI application in the Delphi\Demos directory, but neither solution has been exhaustively tested. Any feedback would be welcome.

When an MDI Child Form is minimized at design time, upon running weird effects occur

Description

Reported by Ricky Jung; checked by Neil Booth
Example that shows the weird effects:

Create an empty form. (This is the Parent Form)

In the Object Inspector, set FormStyle to fsMDIForm.

Create another empty form (This is the child form)

In the Object Inspector, set FormStyle to fsMDIChild and WindowState is wsMinimized

Run

Upon running, the child window is not minimized (though upon clicking it becomes minimized)
The real weird things happen when you have controls (like Edits or Labels) on the Parent Form: they disappear (Label) or 'peep through' the child window (Edit)

Comment from checker: This is certainly not the behaviour a reasonable person would expect. As it does not happen in Delphi 1.0, I would expect this to be a VCL bug rather than the notoriously bug-ridden Windows MDI implementation

Solution / workaround

Make the WindowState of the child form wsNormal at design time, and in the OnCreate handler of the child form, set its WindowsState to wsMinimized.
This does not change the wrong display of the controls on the Parent form, however!

With multiple child windows, if you maximize and close one, the other child windows will have their close ('x') button greyed out, however the button is still active, and will close the window if clicked.

Description

Reported by Matthew Estela; comment by Brad Stowers; fix by Raoul DeKezel

Reproducing the bug:
The bug is evident even in imagedit. Start imagedit, and create 3 new bitmaps. Maximize the last bitmap, then close it. The one behind will be maximised (I've always thought it to be strange windows behavior, but not delphi's fault), and the X will be greyed out. If you click the X, it will close the window. The same holds for the other windows.

A sample program in Delphi has been prepared by Raoul DeKezel. You can download the sources (which demonstrate the bug AND a workaround) here: Pr0372.zip.

Why it's a bug:
The correct behavior would be for the button not to be greyed. This is evident in products not developed in delphi, eg word, photoshop.

Possible cause:
Don't know. A friend supposed it has something to do with the way delphi creates an invisible window to control behavior of the visible ones, and that this was complicating things somehow.

Version:
I'm using delphi 3.0, searching dejanews has revealed it is common to all versions of delphi.
I've tested on win95, win95sp1, NT4workstation sp3, NT4server sp3.

Additional information, by Brad Stowers:
I've found that this only occurs with MDI apps that use menu merging. That is, the MDI parent form has a menu, and the MDI child form has a menu that is merged into the parent. If the MDI child does not have a menu, the problem does not occur. It seems to indicate the bug is somewhere in the menu VCL code, but I haven't been able to pinpoint the exact cause of the problem.

Solution / workaround

Use Raoul DeKezel's workaround; it's in the source code of project Pr0372.
To install the patch in your application :

• Copy the method TForm1.OnAppIdle below in your MDI main form.
• Call that method at idle time. A way of doing that is to copy the TForm1.FormCreate method below.
• MDI children dont need any change.