SetFocus will nicht ...

[himitsu]

Zitat von jaenicke:

Denn das OnActivate passiert ja gerade erst beim Anzeigen des Fensters.

Angezeigt ist es schon ... das war OnShow.

OnActivate ist, wenn das Fenster den Fokus bekommen hat,

[TERWI]

OnActivate habe ich gerade deswegen genommen, weil:
- Alle Units/Klassen sind dann initialisiert.
- Die MainForm wird (das erste mal) gestartet.
... so weit ich das alles richtig verstanden habe.

Zitat:

OnActivate ist, wenn das Fenster den Fokus bekommen hat

KORREKT !
... durch was & wen auch immer ...
Beim Programmstart auf jeden Fall.
ABER EBEN NICHT (mehr) wenn die procedure durch ist und es das LOGWIN gibt !
Da kann ich zuweisen/intitalisieren was ich will - geht einfach nicht
Auch das MainHandle an den LOGGER geben und dort SetForeGround o. ä. machen hilft nicht

Damit hab ich mich mal ne Zeit lang selbst vereimert.
Und dass das erneute Ausführen meiner Initialisierung eben nicht noch passiert, gibt es das Flag "FIsInit".
... wenn ich das versehentlich auskommentiert hatte, .... oh weia.
Ich weiß, nicht ganz sauber aber wenn man drauf achtet funzt das 1A !

Was den Focus angeht, hatte ich da vorhin eine Idee...
Bastle grade dran und gebe noch "Bescheid".

[himitsu]

Das sind sie auch so.

OldCreateOrder sollte man aber auf False stellen, falls es das nicht ist. (das wird True, wenn man extrem uralte Units/Forms in der IDE öffnet und kein OldCreateOrder nicht in der DFM stand ... bei neuen Forms ist es False)
OnCreate wurde früher im Create ausgeführt, aber nun erst im AfterCreate.

[TERWI]

Zum besseren Verständnis:

Jede Unit/Klasse die ich verwende hat jeweils eigene Initialisierungen für sich selbst mit:
- OnCreate (Elementares intern)
- OnDestroy (Dito)
für eigenen internen Kram, automatisch beim Programmstart zur elementaren Initialisierung.
Dazu hat jede Klasse die Funktionen
- OnInit mit Parametern, die erst zum Programmstart bekannt werden (z.B. INI-File)
- OnExit zur sicherung zwischenzeitlicher Änderungen intern eigen erzeugter Daten
welche ich in der MainForm eben in Activate/OnDestroy vor der "Zerstörung" allem anderen aufrufe.
Da kann ich sicher sein, das alles Grundlegende sonstwie definitiv passiert ist und ich alles weitere passend einstellen kann.

Da wird nix verbogen, geschachert, manipuliert oder sonstwas - straight wie es das Proggie braucht wird initialisiert und umgekehrt ggf. gesichert und freigegeben.

Wenn alles an der richtigen Stelle richtig gemacht wird, lüppt dat wie anne Schnur getreckt.
Loggo... wenn da nicht manchmal so Kleinigkeiten einem den Spaß vermiesen.

[jaenicke]

Zitat von himitsu:

OnActivate ist, wenn das Fenster den Fokus bekommen hat,

Ich meinte im Prozess des Anzeigens, denn OnActivate wird ansonsten ja auch noch viel öfter beim Fokuswechsel aufgerufen.

Das Problem tritt bei mir auch auf, wenn ich das zweite Fenster direkt im OnActivate anzeige. Das ist aber ja auch logisch, dass man während des Wechsels des Fokus nicht sinnvoll weitere Fokuswechsel in den Griff bekommt...

Wenn ich das Fenster stattdessen wie vorgeschlagen einfach nach der kompletten Anzeige in einer eigenen Message anzeige, klappt es auch mit dem Fokus:

Delphi-Quellcode:

const
  WM_TEST = WM_APP + 100;

type
  TForm235 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
  protected
    procedure WmTest(var Msg: TMsg); message WM_TEST;
  public
    { Public-Deklarationen }
  end;

var
  Form235: TForm235;

implementation

{$R *.dfm}

procedure TForm235.FormCreate(Sender: TObject);
begin
  PostMessage(Handle, WM_TEST, 0, 0);
end;

procedure TForm235.WmTest(var Msg: TMsg);
begin
  Form236.Show;
  SetFocus;
end;

[himitsu]

Stimmt, direkt in OnCreate und OnShow geht es nicht, wenn man sich alle Fenster beim Start erstellen lässt,
da die andere Form natürlich erst nach der MainForm erstellt wird.

Auch die zweite Form selber erstellen, hat einen Haken, denn PopupMode funktioniert noch nicht, weil die MainForm erst als MainForm registriert wird, nachdem sie vollständig erstellt wurde. (wobei man das eventuell mal als Bug melden könnte)

Ich mach es mit mit sowas einfach nur noch einfach.

Delphi-Quellcode:

procedure TForm10.FormCreate(Sender: TObject);  // oder besser im OnShow
begin
  ...
  TThread.ForceQueue(nil, procedure  // es war echt schwachsinnig den Bugfix für Queue als ForceQueue zu bennen, anstatt es "richtig" zu machen.
    begin
      //Form11.Show;
      //SetFocus;
      ShowWindow(Form11.Handle, SW_SHOWNOACTIVATE);
      Form11.Visible := True;
    end);
end;

[jaenicke]

Daran hatte ich auch gedacht, aber das gibt es ja noch nicht so lange.

Der Effekt ist ja der gleiche.

[TERWI]

Wenn ich ehrlich bin: Hab ich nicht wirklich verstanden ....
Was macht/bewirkt denn TThread.ForceQueue ?
@jaenicke
Welche Form hier (Main, Logger) entspricht denn bei deinem beispiel TForm235, TForm236 ?

Ich hab das hier momentan mal anders gelöst.
Inspiriert durch eine alte Splash-Screen-Demo habe ich meinem Logger eine Init-Prozedure spendiert und in die DPR eingetragen.
(Verkürzte Version meines "neuen" Projekts, nach MainForm-Problem)

Delphi-Quellcode:

program ZATTOO;

uses
  Vcl.Forms,
  Logger5 in 'Logger5.pas' {LOGWIN},
  ZAT_MAIN in 'ZAT_MAIN.pas' {ZATMain},
  LAV_Player in 'LAV_Player.pas' {LAV};

{$R *.res}

begin
  LOGGER.Init;
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TZATMain, ZATMain);
  Application.CreateForm(TLAV, LAV);
  Application.Run;
end.

Das sieht zwar hier so aus, als wenn der Logger eine Form ist, ist aber eine normale Unit, die sich selbst de-/intialisiert und ihr Fenster selbst erzeugt.
(Das hat den Grund darin, das es den Logger bereits gibt, bevor alles weitere initialisiert/startet und ich auch schon FormCreate's mitloggen kann)

Das geht problem- und tadellos.
MainForm hat nun nach dem Start trotz Logger-Fenster den Fokus.

[jaenicke]

Zitat von TERWI:

Wenn ich ehrlich bin: Hab ich nicht wirklich verstanden ....
Was macht/bewirkt denn TThread.ForceQueue ?

Das steht gut erklärt in der Doku, was auch daran liegt, dass es erst mit Delphi 10.2 eingeführt wurde:
https://docwiki.embarcadero.com/Libr...ead.ForceQueue
Der Code wird außerhalb des aktuellen Kontexts ausgeführt, wenn die Anwendung idle ist. Das ist der gleiche Effekt wie in meinem Beispiel. Es wird einfach später ausgeführt, nicht in dem Moment des OnActivate-Ereignisses.

Zitat von TERWI:

@jaenicke
Welche Form hier (Main, Logger) entspricht denn bei deinem beispiel TForm235, TForm236 ?

235 = Main, 236 = Logger

[himitsu]

Es macht eigentlich das, was man von TThead.Queue erwartet, und das gibt es schon länger.
-> Funktion in die Queue legen und später ausführen

Nur Queue macht, wenn im Hautpthread aufgerufen, garnicht das, was man denkt, sondern es führt den Code sofort aus, so als hätte man stattessen Synchronize benutzt.