Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi wieso hat jede anwendung in delphi zwei handles? (https://www.delphipraxis.net/81037-wieso-hat-jede-anwendung-delphi-zwei-handles.html)

SirThornberry 19. Nov 2006 20:48

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.

jbg 20. Nov 2006 11:43

Re: wieso hat jede anwendung in delphi zwei handles?
 
Zitat:

Zitat von Phoenix
Eben nicht. Das war irgendwie der Trick an der Geschichte. Die Variable wurde vorbelegt und erst in einer später aufgeführten Unit wurde Forms includiert

Da Frage ich mich aber trotzdem, wie man an "Application: TApplication" ran kommen will, ohne Forms einzubinden. Vielleicht wild im Arbeitsspeicher herumschreiben?

Der schöne Günther 14. Dez 2015 10:28

AW: Re: wieso hat jede anwendung in delphi zwei handles?
 
Zitat:

Zitat von Elvis (Beitrag 552171)
und musste feststellen, dass sie dort tatsächlich ein Stringliteral benutzen. :wall:
Es gibt also keinen hübschen, delphischen Weg. Du müsstest schon den Klassennamen über die Windows API ändern (kA wie/ob das geht), oder einfach damit leben.

Fast zehn Jahre vergingen, Generationen an Delphi-Programmierern kamen und gingen, die Situation hat sich aber immer noch nicht geändert, richtig?
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.

himitsu 14. Dez 2015 10:49

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?

Der schöne Günther 14. Dez 2015 13:17

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:
    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);
Ich rege mich nur auf dass WindowClass eine Record-Variable im implementation-Teil ist. Ich komme also von außen auch nicht dran.
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');

himitsu 14. Dez 2015 13:56

AW: wieso hat jede anwendung in delphi zwei handles?
 
Zitat:

Zitat von Der schöne Günther (Beitrag 1324399)
Ist mir trotzdem unverständlich warum man das so fest einbacken muss.

Um mal die Worte eines bekannten Embarcaderomitarbeiters zu benutzen: "Ist halt so."

Zitat:

Zitat von Der schöne Günther (Beitrag 1324399)
Ich rege mich nur auf dass WindowClass eine Record-Variable im implementation-Teil ist. Ich komme also von außen auch nicht dran.

Die das lässt sich problemlos durch eine eigene TWndClass ersetzen, indem man selber eine Fenster-Klasse "TApplication" bei Windows registriert, und zwar vor dem Laden von Vcl.Forms Vcl.Controls .

Nur lpszMenuName, lpszClassName und lpfnWndProc lässt sich nicht ändern.
Letzteres doch, durch hooken von MSDN-Library durchsuchenDefWindowProc, bzw. indem mach GWL_WNDPROC nach dem Laden von Vcl.Controls wieder umschreibt.


Was willst du eigentlich erreichen?

Der schöne Günther 14. Dez 2015 16:33

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.

himitsu 15. Dez 2015 09:02

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:
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;
GetWindowThreadProcessId + PostThreadMessage(WM_QUIT) an den GUI-Thread (oder an alle Threads, wo Fenster dran hängen)


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:00 Uhr.
Seite 2 von 2     12   

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