Delphi: Repaint form in FormShow - delphi

Question

I open Form2.ShowModal in FormMain. I want the application to show Form2 intact while doing some database access (this is not about the new data to be shown). However, while FormShow is executed, just the outer border and some broken parts are displayed, some broken parts of FormMain show through. It's ugly.
I have not been able to find a way to make Delphi repaint the Form immediately and then doing the time-consuming MyOpenData procedure. After concluding MyOpenData everything is fine.
procedure TForm2.FormShow(Sender: TObject);
begin
Invalidate;
Refresh;
MyOpenData; { needs some seconds of database accesses }
end;
Alternative:
procedure TForm2.FormShow(Sender: TObject);
begin
Invalidate;
Refresh;
SendMessage(Handle, wm_paint, 0, 0);
PostMessage(Handle, wm_OpenMyData, 0, 0); { executes well, but no solution)
end;
This doesn't work either. I thought SendMessage() waits for the message being done. But no Paint is done before MyOpenData. The form always looks broken till the procedures finishes. Besides this, the routines are executed fine. I tried all these commands combined or separately.
What am I missing? Thanks in advance!
How do you start time-consuming routines that need to run when opening a form?
(Delphi XE7 on Windows 7 64 bit)

Answer 1

uses
WinApi.Windows;
const
WM_AFTER_SHOW = WM_USER + 1; // custom message
WM_AFTER_CREATE = WM_USER + 2; // custom message
private
procedure WmAfterCreate(var Msg: TMessage); message WM_AFTER_CREATE;
procedure WmAfterShow(var Msg: TMessage); message WM_AFTER_SHOW;
procedure TForm1.WmAfterCreate(var Msg: TMessage);
begin
DoSomeThingAfterCreate();
ShowMessage('WM_AFTER_CREATE received!');
end;
procedure TForm1.WmAfterShow(var Msg: TMessage);
begin
DoSomeThingAfterShow();
ShowMessage('WM_AFTER_SHOW received!');
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
// Some code...
PostMessage(Self.Handle, WM_AFTER_CREATE, 0, 0);
end;
procedure TForm1.FormShow(Sender: TObject);
begin
// Some Code...
PostMessage(Self.Handle, WM_AFTER_SHOW, 0, 0);
end;

Answer 2

There simply isn't enough information given to make any specific recommendations here, IMO.
I'm going to guess that MyOpenData() sets up some kind of data state that Form2 relies upon. If this is the case, then you probably want to call it BEFORE calling Form2.ShowModal. In no case should you be calling either invalidate or refresh inside of the OnShow handler because they both trigger OnShow.
Watch the video I made for CodeRage 9 entitled, "Have You Embraced Your Software Plumber Lately?" (search YouTube for 'coderage software plumber') as this is the exact topic I'm addressing in this video -- the whole plethora of issues involved in initializing forms and objects, along with the timing issues specific to forms.
I don't discuss issues with data-aware controls specifically, but they're pretty much the same. It can be problematic setting up the DB state from inside the form that depends upon that state in order to properly initialize itself. There's an inherent race-condition that is easily avoided by doing your dependent initialization first, then injecting that dependency into the form.
If DBs are involved, you have to inject SOMETHING into the form: either the DB reference (usually through a global variable); a table (either a global variable or a form variable); or a current record (usually a form variable). The nice part about using DB-aware controls is that the initialization is always implicit, and you don't have to inject anything. The bad part about using DB-aware controls is, the initialization is ALWAYS IMPLICIT, and you have no EXPLICIT control over initialization sequences. By doing EXPLICIT injection of DB dependencies, you side-step the timing issues. It's a little more work (not much), but you don't have to deal with stuff like this.
In any case, if the form needs a current record to initialize its fields, you can't display the form until the record has been selected, and you can't make the record selection part of the form's initialization process without risking concurrency issues. It can be done, but you're making one heck of a mess out of it.