What is TApplication.Handle
?
The Delphi help says:
TApplication.Handle
Provides access to the window handle of the main form (window) of the application.
property Handle: HWND;
Description
Use Handle when calling Windows API functions that require a parent window handle. For example, a DLL that displays its own top-level pop-up windows needs a parent window to display its windows in the application. Using the Handle property makes such windows part of the application, so that they are minimized, restored, enabled and disabled with the application.
If i focus on the words "the window handle of the main form of the application", and i take that to mean the window handle of the main form of the application, then i can compare:
MainForm
of the Application
but they are not the same:
Application.MainForm.Handle: 11473728
Application.Handle: 11079574
So what is Application.Handle
?
Application
's MainForm
, then why don't they match?Application
's MainForm
, then what is it?Really what i'm asking is: What is the design rationale that makes Application.Handle exist? If i can understand the why, the how should become obvious.
Update Understanding through a game of twenty questions:
In talking about the solution of making a window appear on the taskbar by making its owner null
, Peter Below in 2000 said:
This can cause some problems with modal forms shown from secondary forms.
If the user switches away from the app while a modal form is up, and then back to the form that showed it, the modal form may hide beneath the form. It is possible to deal with this by making sure the modal form is parented [sic; he meant owned] to the form that showed it (using
params.WndParent
as above)But this is not possible with the standard dialogs from the
Dialogs
unit and exceptions, which need more effort to get them to work right (basically handlingApplication.OnActivate
, looking for modal forms parented to Application viaGetLastActivePopup
and bringing them to the top of the Z-order viaSetWindowPos
).
He also talked about using the new Windows extended style that forces a window to appear on the taskbar (when the normal rules of making it un-owned is insufficient, impractical, or undesirable), by adding the WS_EX_APPWINDOW
extended style:
procedure TForm2.CreateParams(var Params: TCreateParams);
begin
inherited CreateParams( params );
Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW;
end;
But then he cautions:
If you click on a secondary forms taskbar button while another app is active this will still bring all the applications forms to front. If you do not want that there is option
Who is bringing all the forms to the front when the form's owner is still Application.Handle
. Is Application doing this? Why is it doing this? Rather than doing this, shouldn't it not be doing this? What is the downside of not doing this; i see the downside of doing it (system menu's don't work propertly, taskbar button thumbnails are inaccurate, Windows® shell cannot minimize windows.
In another post dealing with the Application
, Mike Edenfield says that the parent window sends other window's their minimize, maximize and restore messages:
This will add the taskbar button for your form, but there are a few other minor details to handle. Most obviously, your form still receives minimize/maximize that get sent to the parent form (the main form of the application). In order to avoid this, you can install a message handler for WM_SYSCOMMAND by adding a line such as:
procedure WMSysCommand(var Msg: TMessage); WM_SYSCOMMAND; procedure TParentForm.WMSysCommand(var Msg: TMessage); begin if Msg.wParam = SC_MINIMIZE then begin // Send child windows message, don't // send to windows with a taskbar button. end; end;
Note that this handler goes in the PARENT form of the one you want to behave independantly of > the rest of the application, so as to avoid passing on the minimize message. You can add similar > code for SC_MAXIMIZE, SC_RESTORE, etc.
How is it that minimize/maximize/restore messages for my Windows® windows are not going to my window? Is this because messages destined for a window are sent, by Windows® to the window's owner? And in this case all the forms in a Delphi application are "owned" by Application
? Does that not mean that making the owner null:
procedure TForm2.CreateParams(var Params: TCreateParams);
begin
inherited;
Params.WndParent := 0; //NULL
end;
will remove Application
and it's window Handle from interfering with my form, and Windows should once again send me my mimimize/maximize/restore messages?
Perhaps if we compared and contrasted now a "normal" Windows application does things, with how Borland initially designed Delphi applications to do things - with respect to this Application
object and it's main loop.
Application
object solving?Obviously Borland realized the flaw in their initial design. What was their initial design, what problem was it solving, what is the flaw, what was the re-design, and how does it solve the problem?
The reason for the application window has a bit of a sordid history. When developing Delphi 1, we knew we wanted to use "SDI" (windows scattered all over the desktop) ui model for the IDE. We also knew that Windows sucked (and still does) at that model. However we also noticed that Visual Basic at that time employed that model and it seemed to work well. Upon further examination, we found that VB used a special "hidden" parking window which was used as the "owner" (Windows blurs the notion of parent and owner at times, but the distinction is similar to VCL) for all the other visible windows.
This is how we solved the "problem" where the windows containing the main menu was rarely ever focused so processing Alt-F for the File menu simply wouldn't work. By using this central parking window as an intermediary, we could more easily keep track of and route messages to the appropriate windows.
This arrangement also solved another issue where normally multiple top level windows were entirely independent. By making the application handle the "owner" of all these windows, they would all behave in concert. For instance, you may have noticed that when you select any of the application windows, all the application windows move to the front and retain their z-order relative to each other. This would also make the application minimize and restore as a functional grouping.
That is a consequence of using this model. We could have manually done all this work to keep things straight, but the design philosophy was to not re-invent Windows, but to leverage it where we could. That is also why a TButton or a TEdit is really a Windows "User" BUTTON and EDIT window class and style, respectively.
As Windows evolved, that "SDI" model began to fall out of favor. In fact Windows itself began to become "hostile" to that style of application. Starting with Windows Vista and continuing to 7, the user shell doesn't seem to work well with an application using a parking window. So, we set out to shuffle things around in VCL to eliminate the parking window and move its function into the main form. This presented several "chicken and egg" problems whereby we need to have the parking window available early enough in the application initialization so that other windows can "attach" to it, but the main form itself may not be constructed soon enough. TApplication has to jump through a few hoops to get this to work, and there have been a few subtle edge cases that have caused issue, but most of the problems have been worked out. However, for any application you move forward, it will remain using the older parking window model.