Fenster schließt sich nicht

[QuickAndDirty]

Ich würde sagen du darfst dein "Ereignis" nicht in OnShow aufrufen.
Ich habe früher für sowas in der Regel einen TTimer verwendet der in OnShow aktiviert wird und dann,
wenn die MessageQueue bock hat aufgerufen wird und sich selbst direkt disabled und die Aktion die ich möchte "direkt nach dem Aufbau des fensters" ausführt.
"PostMessage" macht aber ansich das Gleiche und legt auch einfach eine Message auf die Queue die dann, wenn alle anderen Messages(paint, focus, MouseUp) durch sind abgearbeitet werden.

[himitsu]

Statt PostMessage und Timer verwende ich hier gern das Thread.Queue

Delphi-Quellcode:

TThread.ForceQueue(nil, procedure  // im OnShow oder OnCreate/Create
  begin
    ...
  end);

ACHTUNG: ForceQueue statt Queue, da Emba zu dämlich war Queue zu reparieren und den "Bugfix" anders nannte. (im VCL-Thread aufgerufen, führt TThread.Queue den Code sofort aus ... anstatt dieses falsche IF einfach zu löschen, wurde eine neue Funktion gebaut, die endlich das macht, was die Funkion "Queue" laut ihrem Namen beheuptet zu tun)

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1521148)

im VCL-Thread aufgerufen, führt TThread.Queue den Code sofort aus ... anstatt dieses falsche IF einfach zu löschen, wurde eine neue Funktion gebaut, die endlich das macht, was die Funkion "Queue" laut ihrem Namen beheuptet zu tun)

Ich verwende diese Funktionalität allerdings auch, um Zugriffe threadsicher zu machen. Ich kann so einfach Queue aufrufen, ohne zu prüfen, ob ich schon im Hauptthread bin. Deshalb hätte ich es schlecht gefunden, wenn das geändert worden wäre, auch wenn ich deine Argumentation natürlich verstehe.

[himitsu]

Man könnte aber auch einfach immer und überall ForceQueue aufrufen, egal wo. (in Threads verhält es sich gleich, nur im Hauptthread macht es "auch" das, was man sich vom "Queue" denken würde)

TThread.Queue verhält sich im Hauptthread aufgerufen wie ein Synchronize.



Synchronisation: (egal ob Queue oder Synchronize)
* alles im Hauptthread, da ist es nutzlos (bzw. bringt nur unnötig Overhead)
* zwischen Thread geht es
* zwischen Thread(s) und Hauptthread ... im Hauptthread ist es unnötig, da Jener sowieso gerade "blockiert" ist (aber als Doku, bzw. damit es überall gleich ist, würde ich es im Hauptthread als "vertretbar" ansehen)

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1521148)

Statt PostMessage und Timer verwende ich hier gern das Thread.Queue

Delphi-Quellcode:

TThread.ForceQueue(nil, procedure  // im OnShow oder OnCreate/Create
  begin
    ...
  end);

ACHTUNG: ForceQueue statt Queue, da Emba zu dämlich war Queue zu reparieren und den "Bugfix" anders nannte. (im VCL-Thread aufgerufen, führt TThread.Queue den Code sofort aus ... anstatt dieses falsche IF einfach zu löschen, wurde eine neue Funktion gebaut, die endlich das macht, was die Funkion "Queue" laut ihrem Namen beheuptet zu tun)

Danke, ForceQueue funktioniert!

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1521163)

Man könnte aber auch einfach immer und überall ForceQueue aufrufen, egal wo. (in Threads verhält es sich gleich, nur im Hauptthread macht es "auch" das, was man sich vom "Queue" denken würde)

Das möchte ich an der Stelle aber gar nicht. ;-) Und ich (und auch viele andere, wenn ich so fremde Quelltexte anschaue) verlasse mich darauf, dass das auch so bleibt.

[himitsu]

ForceQuere zu erfinden war eh eine blöde Idee.

Wäre schöner gewesen sie hätten Queue repariert.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1521178)

Wäre schöner gewesen sie hätten Queue repariert.

Wie schon geschrieben:
Damit hätten sie die Kompatibilität gebrochen und alte Quelltexte hätten nicht mehr funktioniert.

[Uwe Raabe]

Ich bin da voll bei Sebastian. Niemand hatte Queue in der Form verwendet, die ForceQueue implementiert. Hätten Sie Queue geändert, hätten einige ihren Quelltexte ändern müssen. Nun hat man die Wahl - finde ich besser als den potentiellen Ärger bei einem Breaking Change.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1521178)

ForceQuere zu erfinden war eh eine blöde Idee.

Ich bin da ganz froh drum, das nutze ich gerne zum zeitlichen Entkoppeln.
Dafür ist es super geeignet :stupid: Vielleicht passt der Name dafür nicht ganz.