Getting rid of the initial flash of a WS_MAXIMIZE child

How can I open an MDI child form so that it's initially in a maximized state? Every time I try, it appears in its normal size, then maximizes visibly. I can't hide it because Delphi won't let me, and if I trick it by hiding it in CreateParams, it's maximized for a split second (just after OnShow()), then is reduced to normal size, then is re-maximized. This is all happening somewhere after OnShow() and I can't seem to stop it ... I just need it to open already maximized, and all ready to go. ... Help!

One thing you might have noticed is that child forms set with the wsMaximized property have a visible flash when they're first created. First they're created in a normal state, then they maximize. This is more annoying than problematic.

For those of you who are experienced in mucking about with form properties, you might think that setting the form's window style to WS_MAXIMIZE in the CreateParams method would do the trick. Alas, that doesn't work either. But don't worry, there's a very simple solution.

One of the ways you can prevent the user from seeing background operations on a window is to prevent it from painting, then having it refresh after the changes have been made. To the user, it will appear as if the screen was automagically changed in the blink of an eye. With respect to opening up a maximized MDI child form in an MDI application, this is exactly the type of thing we're going to do.

The specific function that allows us to prevent screen painting is a WinAPI function called LockWindowUpdate. LockWindowUpdate takes a single parameter &mdash the handle of the window &mdash and prevents it from painting until LockWindowUpdate is called again with a parameter of '0.' So, with respect to our particular problem, to prevent a maximized MDI child from flashing at create, you enclose its create statement between two LockWindowUpdate calls like so:

MyMDIChild := TMyMDIChild.Create(Application);

Pretty simple, huh? Notice that I locked the screen painting with respect to the MDI form, not the MDI child. That's important, because if you tried to lock the update for the child, you'd get an error because the handle is invalid. In any case, use this technique for all your MDI applications to avoid the initial flash.