Delphi: Was ist Application.Handle?

https://stackoverflow.com/questions/2204804

18-09-2019
|

Frage

Was ist TApplication.Handle?

Wo kommt es her?
Warum gibt es sie?
Und vor allem: warum alle Formen haben es als ihre Eltern Fenstergriff

Die Delphi-Hilfe sagt:

TApplication.Handle

Ermöglicht den Zugriff auf den Fenstergriff   der Hauptform (Fenster) der   Anwendung.
property Handle: HWND;
Beschreibung:

Verwenden Sie Handle, wenn Windows-API-Aufruf   Funktionen, die ein übergeordnetes Fenster erfordern   Griff. Zum Beispiel kann eine DLL,   zeigt sein eigenes Top-Level-Pop-up   Fenster muss ein übergeordnetes Fenster zu   Anzeige der Fenster in dem   Anwendung. Mit Hilfe der Eigenschaft Handle   macht solches Fenster Teil der   Anwendung, so dass sie   minimiert, wieder hergestellt, aktiviert und   deaktiviert mit der Anwendung.

Wenn ich auf die Worte konzentrieren „ das Fenster-Handle des Hauptformulars der Anwendung “, und ich nehme das bedeuten das Fenster-Handle des Hauptformulars der Anwendung , dann kann ich vergleichen:

„das Fenster-Handle des Hauptformulars der Anwendung“ mit
das Fenster-Handle des MainForm des Application

, aber sie sind nicht das gleiche:

Application.MainForm.Handle: 11473728
Application.Handle: 11079574

Also, was ist Application.Handle?

Wo kommt es her?
Was Windows® Fenstergriff ist es?
Wenn ist der Windows®-Fenstergriff des Application der MainForm, warum sie nicht übereinstimmen?
Wenn es nicht das Fenster-Handle des Application der MainForm, was ist es dann?
Noch wichtiger ist: Warum ist es das ultimative ~~Eltern~~ Eigentümer von jeder Form
Und das wichtigste: Warum alles drunter und drüber geht, wenn ich versuche, eine Form zu haben sein ~~unparented~~ unowned (so kann ich es auf der Task-Leiste angezeigt werden), oder versuchen, so etwas wie IProgressDialog verwenden ?

Wirklich, was ich frage ist: Was ist das Design Gründe, die Application.Handle existieren macht? Wenn ich das Warum verstehen kann, sollte die, wie offensichtlich werden.

Aktualisieren Verstehen durch ein Spiel von zwanzig Fragen:

Im Gespräch über die Lösung ein Fenster machen erscheinen auf der Taskleiste von seinem Besitzer null machen, Peter Unten im Jahr 2000 sagte :

Dies kann einige Probleme mit modalen Formen verursacht gezeigt aus   Sekundärformen.

Wenn der Benutzer schaltet aus der App während eines modalen entfernt   Form ist, und dann zurück zu der Form, die sie zeigte, die modalen bilden   unter der Form verbergen. Es ist möglich, sich damit zu befassen, indem sichergestellt   die modale Form wird [sic parented; Er meinte damit im Besitz] zu der Form, die sie zeigte (unter Verwendung von   params.WndParent wie oben)

Dies ist jedoch nicht möglich, mit dem Standard   Dialoge von der Dialogs Einheit und Ausnahmen , die mehr Aufwand muß   bekommen sie Recht (im Grunde Umgang mit Application.OnActivate zu arbeiten,   Suche modale Formulare parented auf Anwendung über GetLastActivePopup   und bringt sie an die Spitze der Z-Ordnung über SetWindowPos).

Warum endet eine modale Form hinter anderen Formen hochnäsig?
Was normalerweise Mechanismus eine modale Form nach vorne bringt, und warum ist es nicht funktionsfähig hier?
ist Windows® verantwortlich für Fenster gestapelt zeigt. Was schief gegangen ist, dass Windows® ist, die richtigen Fenster nicht angezeigt wird?

Er sprach auch über den neu Windows erweiterte Stil verwenden, die ein Fenster in der Taskleiste angezeigt werden erzwingt (wenn die normalen Regeln macht es nicht im Besitz befindlichen nicht ausreichend ist, unpraktisch oder unerwünscht), von t Zugabeer WS_EX_APPWINDOW erweiterten Stil:

procedure TForm2.CreateParams(var Params: TCreateParams); 
begin 
   inherited CreateParams( params ); 

   Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW; 
end;

Aber er warnt dann:

Wenn Sie auf einem sekundären Formen der Taskleiste klicken, während eine andere App diese aktiv werden weiterhin alle Antragsformulare nach vorne bringen. Wenn du nicht wollen, dass es Option ist

Wer alle Formulare nach vorne bringt, wenn der Eigentümer des Formulars noch Application.Handle ist. Ist Anwendung dies zu tun? Warum tut er das? Anstatt dies zu tun, sollte es nicht nicht dies tun? Was ist die Kehrseite von nicht dies zu tun; Ich sehe die Kehrseite der tun es (Systemmenü nicht propertly arbeiten, Taskleiste Schaltfläche Thumbnails sind ungenau, kann Windows® Shell keine Fenster minimieren.

In einem anderen Beitrag mit dem Application tun hat, Mike Edenfield sagt, dass das übergeordnete Fenster sendet anderen Fensters ihre minimieren, maximieren und wiederherstellen von Nachrichten :

Dies wird die Taskleiste Schaltfläche für Ihr Formular hinzuzufügen, aber es gibt ein paar andere Kleinigkeiten Griff. Am offensichtlichsten Ihre Form erhält noch Minimieren / Maximieren, dass der Muttergesendete Form (die Hauptform der Anwendung). Um dies zu vermeiden, können Sie eine Nachricht installieren Handler für WM_SYSCOMMAND durch eine Zeile wie hinzufügen:
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; 
Beachten Sie, dass diese Prozedur in der ELTERN geht Form der von Ihnen unabhängig voneinander von> den Rest der Anwendung verhalten soll, um die Weitergabe der Nachricht minimieren zu vermeiden. Sie können für SC_MAXIMIZE, SC_RESTORE, etc ähnlich> Code hinzuzufügen.

Wie ist es, die Minimieren / Maximieren / Wiederherstellen Nachrichten für meine Windows® Fenster gehen nicht auf mein Fenster? Ist das da Nachrichten für ein Fenster bestimmt sind, gesendet werden, von Windows® zu kontaktieren Fenster? Und in diesem Fall alle Formulare in einer Delphi-Anwendung „im Besitz“ von Application? Heißt das nicht, dass die Eigentümer null zu machen:

procedure TForm2.CreateParams(var Params: TCreateParams);
begin
   inherited;
   Params.WndParent := 0; //NULL
end;

wird stören meine Form Application und Fenster Griff entfernen, und Windows sollte erneut senden mich mein mimimize / maximieren / wiederherstellen Nachrichten?

Vielleicht, wenn wir verglichen und jetzt eine „normale“ Windows-Anwendung tut Dinge gegenüber, mit wie Borland ursprünglich entwickelt Delphi-Anwendungen, Dinge zu tun - in Bezug auf dieses Application Objekt und es ist Hauptschleife.

, welche Lösung die Application Objekt Lösung war?
Welche Änderung wurde mit späteren Versionen von Delphi gemacht, so dass dieselben Probleme nicht existieren?
Haben die Änderung in späteren Versionen von Delphi nicht andere Probleme vorstellen, dass die inital Anwendungsdesign versucht so schwer zu lösen?
Wie können diese neueren Anwendungen funktionieren immer noch ohne Anwendung mit ihnen zu stören?

Offensichtlich realisiert Borland die Fehler in ihrem ursprünglichen Design. Was war ihr ursprüngliches Design, welches Problem war es zu lösen, was der Fehler ist, was das Re-Design war, und wie sie das Problem nicht lösen?

Lösung

Der Grund für das Anwendungsfenster hat ein bisschen eine schmutzige Geschichte. (Fenster verstreut auf dem Desktop) ui Modell für die IDE bei der Entwicklung von Delphi 1, wussten wir, wir verwenden „SDI“ wollte. Wir wussten auch, dass Windows gesaugt (und tut es immer noch) zu diesem Modell. wir bemerkt jedoch auch, dass Visual Basic zu diesem Zeitpunkt das Modell eingesetzt und es schien gut zu funktionieren. Bei der weiteren Untersuchung fanden wir, dass VB einen speziellen „versteckt“ Park Fenster verwendet, die als „Eigentümer“ verwendet wurde (Windows verwischt die Vorstellung von Eltern und Besitzer manchmal, aber der Unterschied ist ähnlich VCL) für alle anderen sichtbaren Fenster .

Dies ist, wie wir das „Problem“ gelöst, wo die Fenster in das Hauptmenü enthalten, wurden nur selten so die Verarbeitung Alt-F für das Menü Datei einfach fokussiert würde nicht funktionieren. Durch die Nutzung dieser zentralen Park Fenster als Vermittler, könnten wir mehr halten leicht nachvollziehen und Nachrichten an die entsprechenden Fenster.

Diese Anordnung gelöst auch ein anderes Problem, bei dem normalerweise mehrere Top-Level-Fenster waren völlig unabhängig. Indem die Anwendung der „Besitzer“ behandelt all diese Fenster, würden sie alle gemeinsam verhalten. Zum Beispiel haben Sie vielleicht bemerkt, dass, wenn Sie jeder der Anwendungsfenster, alle die Anwendungsfenster nach vorne bewegen und ihre Z-Reihenfolge relativ zueinander behalten. Dies würde auch die Anwendung minimieren machen und als funktionelle Gruppierung wiederherstellen.

Das ist eine Folge dieses Modell zu verwenden. Wir könnte haben manuell all diese Arbeit getan Dinge gerade zu halten, aber die Design-Philosophie war nicht neu zu erfinden, Windows, aber es zu nutzen, wo wir konnten. Das ist auch, warum ein TButton oder ein TEdit ist wirklich Windows "User" und EDIT Fenster Klasse und Stil ist.

Da Windows entwickelt, das „SDI“ Modell begann in Ungnade zu fallen. In der Tat begann Windows selbst auf diese Art der Anwendung „feindlich“ zu werden. Beginnend mit Windows Vista und Weiterbildung bis 7, das Benutzer-Shell scheint nicht gut mit einer Anwendung zu arbeiten, um einen Parkplatz Fenster. So setzen wir die Dinge um die Park Fenster zu beseitigen in VCL zu mischen und seine Funktion in der Hauptform zu bewegen. Dies stellte mehrere „Huhn und Ei“ Probleme, wobei wir früh genug in der Anwendung Initialisierung des Park Fenster haben müssen, so dass andere Fenster können „anhängen“, um es, aber die Hauptform selbst nicht schnell genug aufgebaut werden kann. TApplication hat durch ein paar Reifen zu springen zu bekommen dies zu arbeiten, und es gibt ein paar subtile Grenzfälle gewesen, die Frage verursacht haben, aber die meisten der Probleme gearbeitet worden sind. Doch für jede Anwendung, die Sie vorwärts zu bewegen, wird es bleibt das ältere Park Fenster-Modell.

Andere Tipps

Alle VCL-Anwendungen haben ein „verstecktes“ Top-Level-Fenster genannt Anwendung. Dies geschieht automatisch beim Anwendungsstart erstellt. Unter anderem ist es die Hauptfenster Meldungshandler für VCL - daher Application.ProcessMessages

versteckten die apps Top-Level-Fenster Nachdem hat einige seltsamen Dinge verursachen, deutlich das unvollständige Systemmenü, das in der Taskleiste zeigt, und eine falschen Daumennagel Fenster in Vista. Spätere Versionen von Delphi dies korrigieren.

Allerdings sind nicht alle Fenster haben müssen sie als Eltern von Windows neigt nur besser zu arbeiten, wenn es ist. Jedoch kann jede Form mit Application.CreateForm erstellt wird es als Elternteil hat, und es wird auch durch das Application-Objekt gehört. Da sie im Besitz sind, werden sie befreit werden, sobald Anwendung freigegeben wird. Dies geschieht hinter den Kulissen in Forms.DoneApplication

Von in forms.pas (Delphi 2009) an der Quelle sucht, scheint es, dass sie ein "Master" Fenster in Win32-GUI-Anwendungen zu ermöglichen, Anrufe

erstellen

TApplication.Minimize
TApplication.Restore
etc

Es scheint, dass Nachrichten an die Application.Handle weitergegeben werden gegebenenfalls an die MainForm weitergeleitet, wenn es vorhanden ist. Dies würde es ermöglichen die App zu minimieren zu reagieren, usw., wenn das Hauptfenster wurde noch nicht erstellt. Durch das Projekt Quelle modifizieren können Sie eine delphi App ohne ein Hauptfenster erstellen.

In diesem Fall werden die TApplication Methoden immer noch funktionieren, auch wenn Sie kein Hauptfenster erstellt haben. Nicht sicher, ob ich alle im Sinne bin ergreifend, aber ich habe keine Zeit durch alle den TApplication Code zu gehen.

Per Ihre Fragen:

Wo es her? Es ist der Griff eines Fensters in TApplication.Create
Was Fenstergriff ist es? ein gefälschtes Fenster, das jeder gui delphi App als Teil der TApplication Abstraktion erfordert
Ist es das Fenster Handle des Hauptformulars appliation Nein
Wenn es nicht der Griff der Anwendung Hauptform dann, was es ist? Siehe oben
was noch wichtiger ist: Warum ist sie die Mutter jeder Form vorausgesetzt, Sie haben Recht, dass ihr die Mutter, nehme ich an, dass es so ist, weil es macht es einfach zu finden? alle Formulare in der Anwendung (die Kinder dieser "Master" Form Aufzählen).
und am wichtigsten ist: warum alles drunter und drüber geht, wenn ich versuche, eine Form zu haben sein unparented Ich denke, weil die versteckte „Master“ Form Systemmeldungen bekommt, dass es sollte weitergeben an ihre Kinder und / oder die Hauptform, kann aber die unparented Form nicht finden.

Wie auch immer, das ist mein nehmen auf sie. Sie können sich wahrscheinlich mehr lernen, indem sie an der TApplication Erklärung und Code in forms.pas suchen. Unterm Strich von dem, was ich sehe, ist es ist eine bequeme Abstraktion.

Mit freundlichen Grüßen,

Don

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow