wieso hat jede anwendung in delphi zwei handles?

[Timi-loader]

hallo
also mich wunderte jetzt, als ich ein programm geschrieben habe, welches alle handles auflistet, dass jedes von mir mit delphi geschriebene programm immer 2 handles hat. zum einen TApplication und zum andern beim Standard TForm1.
dieses TForm1 kann ich ja im prinzip umbenennen, indem ich einfach den namen des Form1 änder.

aber wie änder ich den den namen von TApplication? (sonst sieht ja jeder gleich: "ah mit delphi erstellt")

und wieso hat jede anwendung von delphi bei mir immer zwei handles?? (jede andere anwensung macht doch auch nur eins oder)

mfg
:)
Timi-loader

[Waldteufel]

Hi Timi-loader.

Zitat:

Zitat von Timi-loader

also mich wunderte jetzt, als ich ein programm geschrieben habe, welches alle handles auflistet, dass jedes von mir mit delphi geschriebene programm immer 2 handles hat. zum einen TApplication und zum andern beim Standard TForm1.

Die beiden Handles sind einfach einmal das Handle zur Anwendung (engl: application), sowie das Handle zum Formular (engl: form).

Zitat:

Zitat von Timi-loader

dieses TForm1 kann ich ja im prinzip umbenennen, indem ich einfach den namen des Form1 änder.

Genau. Streng genommen änderst du damit den Namen der Formularklasse TForm1 in irgendwas anderes.

Zitat:

Zitat von Timi-loader

aber wie änder ich den den namen von TApplication?

Gar nicht. Die Klasse heißt TApplication und das bleibt so. Vom Rumpfuschen an der VCL und ihrem Drum-und-Dran kann ich nur abraten.

Zitat:

Zitat von Timi-loader

sonst sieht ja jeder gleich: "ah mit delphi erstellt"

Ist das denn so schlimm? Es ist ja keine Schande, mit Delphi zu programmieren.

Gruß,
Waldteufel

[mkinzler]

Für die Kommunikation mit dem Betriebssystem verwendet Delphi ein nicht sichtbares Fenster. Dieses wird durch das Applikationsobjekt erzeugt. Du müßtest also diese Überschreiben umd den handle zu ändern.

[SirThornberry]

Wenn dir das TApplication nicht gefällt dann programmiere einfach NonVCL dann sind deine Anwendungen schön klein und du kannst dich um alles selbst kümmern (also auch die Klassennamen)

[Phoenix]

Alternativ kann er auch TApplication ableiten (und nix verändern) und verwenden - dann ist das Handle halt eins auf SeinEigenerKlassenname.

[SirThornberry]

dann hat er aber das Problem das er die VCL ändern muss oder die unit Forms nicht verwenden sollte damit keine Instanz von TApplication erzeugt wird.

[Phoenix]

Soweit ich weiss geht das mit einem kleinen Getrickse. Man muss nur vor dem EInbinden der Unit Forms in der Projektcode-Datei eine eigene Unit einbinden die im initialization die abgeleitet Application-Klasse erzeugt und der globalen Variable Application zuweist. Dann wird TApplication nämlich soweit ich weiss nicht nochmal erzeugt.

Ist aber schon länger her das ich mit sowas gerabeitet hab, das kann also auch schon deprecated sein. Zumal ging das mit Delphi 5.

[jbg]

Zitat:

Zitat von Phoenix

Soweit ich weiss geht das mit einem kleinen Getrickse. Man muss nur vor dem EInbinden der Unit Forms in der Projektcode-Datei eine eigene Unit einbinden die im initialization die abgeleitet Application-Klasse erzeugt und der globalen Variable Application zuweist.

Du hast dabei aber wohl vergessen, dass du Forms dann in dieser neuen Unit einbinden musst, um auf die Application-Variable zugreifen zukönnen, womit aber der initialization Abschnitt von Forms bzw. Controls bereits ausgeführt vor dem neuen ausgeführt wird, und somit Application bereits erzeugt ist.
Ohne VCL Code Änderung oder API Hooks wird das so nicht gehen.

[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, so dass TApplication nicht nochmal neu erzeugt wurde. Aber das ist inzwischen knapp 6 Jahre her, ich hab echt keine Details mehr im Kopf. Muss mal gucken ob ich die alten Sourcen noch Zuhause in einem meiner zahlreichen Archive hab.

Auf jeden Fall ging das, ohne die VCL auch nur schräg anzugucken geschweige denn anzufassen.

[Elvis]

Ich dachte eben, so naiv wie ich nun mal bin, dass die Borländer einfach den ClassName der Application-Instanz als ClassName für das Fenster nehmen.
Demnach hätte das hier schon gereicht:

Delphi-Quellcode:

type
  MyApplication = class(TApplication);
  PClass        = ^TClass;
begin
  PClass(Application)^ := MyApplication;

  Application.Initialize;
  ...

Als es nicht klappte, schaute ich in die dunklen Abgründe der Forms.pas (*uärks*... :? ) 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.
Ich wüsste nicht was schlimm daran sein könnte. Delphi ist ja nicht peinlich, wie dieses komische Viech namens VB. ;)

[SirThornberry]

eine andere Variante die eventuell funktioniert:
- Unit Forms einbinden
- Application freigeben
- Eigenes von TApplication abgeleitetes Object erstellen und der Instanzvariablen Application zuweisen.

[jbg]

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]

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]

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]

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]

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 DefWindowProc, bzw. indem mach GWL_WNDPROC nach dem Laden von Vcl.Controls wieder umschreibt.


Was willst du eigentlich erreichen?

[Der schöne Günther]

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]

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)