![]() |
Re: wieso hat jede anwendung in delphi zwei handles?
eine andere Variante die eventuell funktioniert:
- Unit Forms einbinden - Application freigeben - Eigenes von TApplication abgeleitetes Object erstellen und der Instanzvariablen Application zuweisen. |
Re: wieso hat jede anwendung in delphi zwei handles?
Zitat:
|
AW: Re: wieso hat jede anwendung in delphi zwei handles?
Zitat:
Das Fenster für meine Message-Loop wird immer "TApplication" heißen und ich habe keine Möglichkeit das zu ändern, richtig? Die TApplication.Instanz zu zerstören und mit einer Unterklassen-Instanz welche eine neue CreateHandle()-Methode mitbringt fühlt sich irgendwie ... gefährlich an. |
AW: Re: wieso hat jede anwendung in delphi zwei handles?
Doch, es hat sich was geändert.
In der Taskleiste ist nicht mehr TApplication, sondern die MainForm. Und da man auch die MainForm im laufenden Betrieb tauschen kann, ist es auch vollkommen legitim, daß es eine MessageOnly-Form gibt, die sich um globale Messages kümmert. Außer daß Borland/Codegear/Embarcadero nach jahrzehnten immernoch nicht kappiert hat, wie man ein Message-Only-Window richtig erstellt. > z.B. HWND_MESSAGE als Owner Oder hat sich diesbezüglich in TApplication.CreateHandle > CreateWindowEx inzwischen was geändert? |
AW: wieso hat jede anwendung in delphi zwei handles?
Ich kenne mich mit dem ganzen Message-Handler-Unterbau nicht wirklich aus, so tief runter habe ich nie gebuddelt. Mir wäre es lieber gewesen dieses TApplication-Fenster zu haben, aber zur Not tut es (wahrscheinlich) auch das "Haupt"formular der VCL-Anwendung.
Ist mir trotzdem unverständlich warum man das so fest einbacken muss. TApplication.CreateHandle() sieht in XE7.1 so aus:
Delphi-Quellcode:
Ich rege mich nur auf dass WindowClass eine Record-Variable im implementation-Teil ist. Ich komme also von außen auch nicht dran.
LHandle := CreateWindowEx(WS_EX_TOOLWINDOW, WindowClass.lpszClassName, {$IFNDEF CLR}PChar{$ENDIF}(FTitle),
WS_POPUP or WS_CAPTION or WS_CLIPSIBLINGS or WS_SYSMENU or WS_MINIMIZEBOX, GetSystemMetrics(SM_CXSCREEN) div 2, GetSystemMetrics(SM_CYSCREEN) div 2, 0, 0, 0, 0, HInstance, nil);
Delphi-Quellcode:
var
WindowClass: TWndClass = ( style: 0; lpfnWndProc: @DefWindowProc; cbClsExtra: 0; cbWndExtra: 0; hInstance: 0; hIcon: 0; hCursor: 0; hbrBackground: 0; lpszMenuName: nil; lpszClassName: 'TApplication'); |
AW: wieso hat jede anwendung in delphi zwei handles?
Zitat:
Zitat:
Nur lpszMenuName, lpszClassName und lpfnWndProc lässt sich nicht ändern. Letzteres doch, durch hooken von ![]() Was willst du eigentlich erreichen? |
AW: wieso hat jede anwendung in delphi zwei handles?
Ich wollte eigentlich einfach nur eine VCL-Anwendung die Aufforderung zum Beenden schicken. Also ein WM_CLOSE (oder WM_QUIT?). Und ich fand es "richtiger" es an das "TApplication"-"Formular" als an das sichtbare Formular zu senden. Naja, egal.
|
AW: wieso hat jede anwendung in delphi zwei handles?
Im Notfall einfach an alle Top-Level-Fenster der Anwendung schicken und schon hat man keine Probleme.
bzw. WM_QUIT an TApplication WM_CLOSE oder WM_QUIT an die TForm. Aber du kannst es dir einfach machen, denn in Delphi reagiert keine TForm/TApplication auf WM_QUIT, sondern der Thread, egal an welches seiner Fenster es geschickt wird. In Kurz:
Delphi-Quellcode:
GetWindowThreadProcessId + PostThreadMessage(WM_QUIT) an den GUI-Thread (oder an alle Threads, wo Fenster dran hängen)
function TApplication.ProcessMessage(var Msg: TMsg): Boolean;
begin if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then if Msg.Message <> WM_QUIT then .. else FTerminate := True; // Application.Terminate; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz