10.3.1: OnActivate wird vor OnCreate ausgeführt

[DieDolly]

Danke für die Demo.

Zitat:

(Erstellt mit D6.. )

412 KiB kompilierter Quellcode, in seiner reinsten Form :thumb:

Sieht gut und verständlich aus. Vom Prinzip her genau wie mein OnPaint-Ansatz, nur dass du mit deiner Umsetzung keine nervige Variable brauchst, um dir den Status zu merken.
Hat Vorteile die nicht mehr zu haben finde ich.

[HolgerX]

Hmm..

Kannst das Test-Tool ja mal gegen deine VMs testen und sehen, wann dort das 'AfterShow' kommt.
Eventuell eine bessere Alternative, wenn das OnActivate kommt, wann es will ;)

[DieDolly]

Verstehe nicht was du damit sagen möchtest?
Ist es OS-abhängig, ob dein Ansatz funktioniert oder nicht?


Edit spät in der Nacht
einen Nachteil habe ich wohl gefunden. Wenn man ein Programm mit diesem Mechanismus ins Systemtray minimiert und zurückholt, wird DoAfterShow trotzdem wieder ausgeführt.
Um eine Zwischenvariable kommt man also in beiden Fällen nicht drumherum. Außer man minimiert das Programm niemals in den Systemtray.

[HolgerX]

Hmm..

Also, wenn ich meine D6 Applikation minimiere und dann wieder hochhole wird bei mir nur OnPaint aufgerufen, jedoch kein OnShow und somit kein AfterShow.
(Windows 8.1 64Bit auf Notebook)

Ich dachte es geht um OnActivate VOR OnShow?
Es sollte doch in der VM falsch sein...

Teste mal mit meinem Tool, ob auch dort AfterShow vor OnCreate kommt...

[DieDolly]

Zitat:

Es sollte doch in der VM falsch sein...

In zwei VMs konnte ich das nicht richtig nachvollziehen. Getestet aber leider nur unter Windows XP und 7.
Ich habe dort dieselben Ergebnisse bekommen wie unter dem Windows 10 Host.

Zitat:

Teste mal mit meinem Tool, ob auch dort AfterShow vor OnCreate kommt...

Windows 10 Host, Windows XP und 7 Gast alles wie es sein soll. Vielleicht doch ein Delphi-Problem (was es bei D6 noch nicht gab) und weniger Windows?

Zum Minimieren:
ich meine zum Systemtray, also komplett weg aus der Taskleiste und nur noch ein kleines Icon im Statusbereich.

[Uwe Raabe]

Zitat:

Zitat von DieDolly (Beitrag 1428532)

Vielleicht doch ein Delphi-Problem (was es bei D6 noch nicht gab) und weniger Windows?

Spielt eigentlich keine Rolle. Wenn es wirklich an der Windows-Version (und vermutlich einem Haufen anderer Bedingungen für das System) liegt, dann kann man das ja in Delphi abfangen und passend lösen. Dazu müsste man es aber halt schon reproduzieren können. Leider genügte keine der bisherigen Beschreibungen dieser Anforderung.

Der Hinweis auf das SetFocusControl und die DPI Umrechnung ist ja durchaus hilfreich. Ohne einen reproduzierbaren Testfall ist es aber nahezu unmöglich den Fehler zu lokalisieren und zu beheben.

[blawen]

Zitat:

Zitat von Uwe Raabe (Beitrag 1428456)

Zitat:

Zitat von blawen (Beitrag 1428450)

Win10 mit 4k+HD Monitor (Mischbetrieb):

Welche DPI hat der primäre Monitor?

150% (144 dpi)

Aktuell habe ich auf besagte Monitor-Kombination keinen Zugriff (Geschäfts-Monitor), aber beim testen mit zwei unterschiedlichen Notebooks (W10, HD-Auflösung) kann ich das Problem problemfrei nachstellen.

Zitat:

Bei mir ist es relativ einfach nachstellbar:

- Neues Projekt
- 2 leere Formulare

Win10 mit 4k+HD Monitor (Mischbetrieb):
- Beide Formulare mit wsMaximized-> 2 Formulare werden geöffnet/angezeigt
- Form1 auf "wsNormal" und Form2 auf "wsMaximized" -> Form2 überdeckt Form1, Form2 kann aber nicht geschlossen werden

Wenn ich nur einen HD-Monitor angeschlossen habe, funktioniert es bei mir auch mit 10.3.1 wie erwartet.
Ebenso funktioniert es mit einer gepatchten 10.2.3 wie erwartet

Sobald die Auflösung > 100% (> 96 DPI) ist, tritt das beschriebene Problem auf. Analog gilt dies bei mir bei einer ungepatchten 10.2.3.

Schlussendlich scheint die Kombination HD/4k keinen Einfluss zu haben, es reicht zumindest bei mir aus, wenn die Auflösung > 100% (> 96 DPI) ist.

[DieDolly]

Zitat:

Schlussendlich scheint die Kombination HD/4k keinen Einfluss zu haben, es reicht zumindest bei mir aus, wenn die Auflösung > 100% (> 96 DPI) ist.

Das könnte noch ein sehr interessantes Problem werden. Ich habe das eben mal nachgestellt und bekomme Create immer vor Activate. Windows 10 Pro 64 bit.

[Edelfix]

Änliches Problem:

https://www.delphipraxis.net/199789-...ml#post1426047

[Uwe Raabe]

Zitat:

Zitat von blawen (Beitrag 1428597)

Sobald die Auflösung > 100% (> 96 DPI) ist, tritt das beschriebene Problem auf.

Es ist vermutlich noch etwas subtiler: Offenbar muss der Primäre Monitor eine Auflösung > 100% haben. In meiner Mischkombination (100% - 100% - 200%) habe ich deutlich weniger Probleme mit High-DPI, vermutlich weil mein Primärer Monitor auf 100% steht.

[Bbommel]

Zitat:

Zitat von Uwe Raabe (Beitrag 1428545)

Der Hinweis auf das SetFocusControl und die DPI Umrechnung ist ja durchaus hilfreich. Ohne einen reproduzierbaren Testfall ist es aber nahezu unmöglich den Fehler zu lokalisieren und zu beheben.

Jepp, das sehe ich ähnlich, daher habe ich auch noch nichts bei Emba gemeldet bisher. Da es in einem anderen Thread (nicht von mir) Thema war, bei dem es auch um die Kombination Rio+Win8.1 ging, hier noch der Hinweis, dass es der VMware Workstation Player in der Version 12 ist. Windows ist die Version 6.3 Build 9600.

Weitere Tests, die ich gerade noch gemacht habe: ändere ich in der VM die Skalierung von den aktuell 125% auf 150%, dann tritt der Effekt ebenfalls auf. Ändere ich die Skalierung auf 100%, dann tritt der Effekt nicht auf.

Ändere ich im Form das Scaled auf "false" (Danke an Edelfix für den Querverweis), dann tritt das Problem nicht mehr auf.

Und die Codestelle, die, wenn das Problem auftritt, letztlich verantwortlich ist, ist die folgende Funktion in VCL.Forms:

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if WindowState = wsMaximized then
  begin
    WindowPlacement.length := SizeOf(WindowPlacement);
    if GetWindowPlacement(Handle, @WindowPlacement) then
    begin
      WindowPlacement.rcNormalPosition.Right := WindowPlacement.rcNormalPosition.Left
        + MulDiv(WindowPlacement.rcNormalPosition.Width, M, D);
      WindowPlacement.rcNormalPosition.Bottom := WindowPlacement.rcNormalPosition.Top
        + MulDiv(WindowPlacement.rcNormalPosition.Height, M, D);
      SetWindowPlacement(Handle, @WindowPlacement);
    end;
  end;
end;

Die letzte Zeile, also das SetWindowPlacement, ist ein WinAPI-Aufruf, durch den dann letztlich das vorzeitige Activate vom Formular ausgelöst wird.

Soweit mein Stand der Forschung. :-)

[DenkDirNix]

Zur grundlegenden Frage "welches Ereignis kommt wann" hatte ich mal ein kleines Tool geschrieben das zu Fragen dieser Art vielleicht interessant ist.

Es werden alle in den WindowProcs() der vorhandenen Kompoonenten sowie in Application.OnMessage() ankommenden Botschaften decodiert und auf CodeSite ausgegeben, außerdem "einige" VCL-Ereignisse. Die Schachtelung wird ggf durch das Einrücken angezeigt.
Mit den CheckBoxen der rechten Hälfte kann man etwas Selektieren, es kommt sonst sehr viel!

Werde das Ganze bei Gelegenheit noch etwas aufhübschen und mit Quellen hier posten.
Wie oben schon gesagt: CodeSite wird benötigt.

[Michael II]

Bei meinem Windows (10.0.17763 Build 17763) und Delphi (10.3 Version 26.0.33219.4899) gleich.

Ich benötige auch nur - wie weiter oben beschrieben wird - 2 Formulare und nur 1 Monitor für Activate vor Create.

Erstes Formular: nix ändern
Zweites Formular: WindowsState=wsMaximized

Wenn ich das nun mit Anzeigeeinstellung >100% laufen lasse, dann werden beide Formulare angezeigt. Beim ersten Formular wie erwartet: Create vor Activate. Beim zweiten Formular: Wider Erwarten wird es angezeigt und Activate vor Create. Formular 2 lässt sich nicht schliessen. (Create 1 -> Activate 2 -> Create 2 -> Activate 1)

Wenn ich Anzeigeeinstellung 100% wähle, dann wird wie erwartet nur Formular 1 angezeigt.

Wenn ich für Formular 2 Scaled=FALSE setze, dann funktioniert's unabhängig von der Anzeigeeinstellung wie erwartet.

[Uwe Raabe]

Zitat:

Zitat von Bbommel (Beitrag 1428611)

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if WindowState = wsMaximized then
  begin

Da fehlt eine Abfrage auf

Delphi-Quellcode:

HandleAllocated

. Das müsste so lauten:

Delphi-Quellcode:

  if (WindowState = wsMaximized) and HandleAllocated then
  begin

[Bbommel]

Zitat:

Zitat von Uwe Raabe (Beitrag 1428645)

Da fehlt eine Abfrage auf

Delphi-Quellcode:

HandleAllocated

.

Danke! Das heißt, das könnte man dann so mit dem Lösungsvorschlag bei Emba melden, oder?

[Michael II]

Genau... Uwe war schneller.. ;-)
Es reicht natürlich auch nur ein Formular und ein Monitor und windowstate=wsmaximized für Activate vor Create. Wenn skaliert wird, dann biegt man hier ab:

Delphi-Quellcode:

procedure TCustomForm.ScaleForCurrentDpi;

    if ShouldScale(self) then

und landet da:

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if WindowState = wsMaximized then

   SetWindowPlacement(Handle, @WindowPlacement); // => OnActivate

Aber da ist das Formular noch im state fsCreating.

[Michael II]

Hoi Uwe

zu deinem Vorschlag

Delphi-Quellcode:

if (WindowState = wsMaximized) and HandleAllocated then
  begin

HandleAllocated ist bei meinem Delphi bereits TRUE.


Es wird deshalb weiterhin Activate vor Create ausgelöst.

Ich schlage deshalb vor:

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if ( WindowState = wsMaximized ) and not ( fsCreating in FFormState )  then
  begin

[Bbommel]

Wenn ich das richtig sehe, dann gibt es den passenden Eintrag im QP sogar schon (allerdings ohne Lösungsvorschlag):

https://quality.embarcadero.com/browse/RSP-23179

Ich werde mal die Erkenntnisse hier aus der Diskussion ergänzen.

[Uwe Raabe]

Zitat:

Zitat von Michael II (Beitrag 1428652)

HandleAllocated ist bei meinem Delphi bereits TRUE.

OK! Ich kann das hier immer noch nicht reproduzieren bzw. hatte noch keine Zeit eine passende VM zu erstellen.

Ich frage mich, ob dieses ScaleNormalSize dort überhaupt immer aufgerufen werden muss. Das ist doch eh nur sinnvoll, wenn das Form beim DPI change bereits sichtbar ist. Vielleicht wäre eine diesbezügliche Abfrage da eher sinnvoll.

[DieDolly]

Wann tritt dieser Fehler denn jetzt genau auf? Es gibt hier soviele Ideen, Vorschläge und Nachbildungen des Fehlers, dass ich nicht mehr durchblicke.
Weiter oben kam dann auch noch Scaled := False hinzu, was die Verwirrung komplett macht.

Soll man Scaled nicht so oder so immer auf False stellen?
Ich benutze grundsätzlich immer Form123.ScaleBy(Screen.PixelsPerInch, originale-auflösung-während-der-entwicklung);

[Bbommel]

Zitat:

Zitat von DieDolly (Beitrag 1428655)

Wann tritt dieser Fehler denn jetzt genau auf? Es gibt hier soviele Ideen, Vorschläge und Nachbildungen des Fehlers, dass ich nicht mehr durchblicke.

Ich glaube, so ganz hundertprozentig konnten wir das noch immer nicht rausarbeiten, welche Konstellation genau für den Fehler sorgt. Bei mir z.B. tritt er innerhalb der VM mit Win8.1 auf, direkt auf meinem normalen Win10 habe ich kein Problem. Uwe aber konnte den Fehler auch unter Win8.1 nicht nachvollziehen, andere wiederum berichten auch unter Win10 von Problemen, die wahrscheinlich die gleiche Ursache haben. Insofern wissen wir es noch nicht ganz genau.

Zitat:

Zitat von DieDolly (Beitrag 1428655)

Weiter oben kam dann auch noch Scaled := False hinzu, was die Verwirrung komplett macht.

Naja, die "bösen" Funktionen werden halt mit scaled=false nicht aufgerufen, insofern dann auch kein Fehler. Das gleiche gilt für den Fall, dass das Fenster nicht maximiert ist.

[Michael II]

Delphi-Quellcode:

OK! Ich kann das hier immer noch nicht reproduzieren bzw. hatte noch keine Zeit eine passende VM zu erstellen.

Hallo Uwe
Ich nutze dazu keine VM, sondern ein Notebook mit einem "normalen" Windows Home mit Anzeige Skalierung 125%, ohne zweiten Monitor
Windows Home Version 10.0.17763 Build 17763
und
Delphi 10.3 Version 26.0.33219.4899 (Ich wiess grad nicht, ob es da bereits ein Update gab (?) und damit vielleicht bereits einen Fix.)

[Delphi.Narium]

Zitat:

Zitat von Bbommel (Beitrag 1428657)

Naja, die "bösen" Funktionen werden halt mit scaled=false nicht aufgerufen, insofern dann auch kein Fehler. Das gleiche gilt für den Fall, dass das Fenster nicht maximiert ist.

Könnte man anhand dieser Aussage den Schluss ziehen:

Wenn eine automatische Größenveränderung / -berechnung eines Formulares durchzuführen ist, ist mit dem Auftreten eines Fehlers (falscher Abfolge der Ereignisse OnCreate und OnActivate), bedingt durch den Aufruf von SetWindowPlacement, zu rechnen?

[Uwe Raabe]

Zitat:

Zitat von Michael II (Beitrag 1428659)

Ich nutze dazu keine VM, sondern ein Notebook mit einem "normalen" Windows Home mit Anzeige Skalierung 125%, ohne zweiten Monitor

Da ich es auf meinem "normalen" Windows trotz Starten auf meinem dritten Monitor mit 200% nicht reproduzieren kann, vermute ich einen Zusammenhang mit der DPI-Einstellung des Hauptmonitors (der hat hier 100%). Dein Notebook-Beispiel passt immerhin zu dieser Annahme. Da meine High-DPI VM vor ein paar Wochen offenbar den Auto-Update-Tod gestorben ist, habe ich aktuell leider keine passende Testumgebung für diese Konstellation. Mein Produktivsystem stelle ich dafür nicht um.

[blawen]

Zitat:

Zitat von Uwe Raabe (Beitrag 1428662)

Zitat:

Zitat von Michael II (Beitrag 1428659)

Ich nutze dazu keine VM, sondern ein Notebook mit einem "normalen" Windows Home mit Anzeige Skalierung 125%, ohne zweiten Monitor

Da ich es auf meinem "normalen" Windows trotz Starten auf meinem dritten Monitor mit 200% nicht reproduzieren kann, vermute ich einen Zusammenhang mit der DPI-Einstellung des Hauptmonitors (der hat hier 100%). Dein Notebook-Beispiel passt immerhin zu dieser Annahme.

Es hängt vom primären Monitor und von der Fenstereigenschaft "Scaled" ab:

- Primär Monitor (4k) auf 100%, Sekundär > 100% -> Kein Fehler feststellbar
- Primär Monitor (4k) > 100%, Sekundär >= 100% -> Der Fehler tritt auf
- Notebook mit HD-Auflösung -> Sobald die Skalierung >100% ist, tritt der Fehler auf
- Wenn beim Minimalbeispiel (2 Forms) beim Form2 "wsMaximized" und "Scaled = False" eingestellt ist, wird das Form2 nicht angezeigt.
- Der Fehler tritt grundsätzlich auch bei W7 Pro auf
- Bei 10.2.3 tritt der Fehler auch auf, wenn aber der Patch von Uwe eingespielt ist, funktioniert es wie gewohnt.

[DieDolly]

Zitat:

Bei 10.2.3 tritt der Fehler auch auf, wenn aber der Patch von Uwe eingespielt ist, funktioniert es wie gewohnt.

Wird Zeit, dass Embarcadero Herrn Raabe einstellt. Er bringt Delphi wenigstens voran :thumb:

[Michael II]

Wenn ich den Code in VCL.Forms und VCL.Controls korrekt lese, dann tritt Activate vor Create auf, wenn WindowState=wsMaximized gesetzt wird, Scaled=TRUE belassen wird, mindestens Windows 6.3 installiert ist und wenn

Winapi.Windows.USER_DEFAULT_SCREEN_DPI <> GetCurrentPPIScreen( )

Bei meinem System:
Winapi.Windows.USER_DEFAULT_SCREEN_DPI 96
GetCurrentPPIScreen( ) 120

=> procedure TCustomForm.ScaleNormalSize(M, D: Integer); wird aufgerufen und damit, weil WindowState = wsMaximized dann irgendwann SetWindowPlacement(Handle, @WindowPlacement); => OnActivate


Falls jemand nach der Änderung (Code unten) (and not ( fsCreating in FFormState)

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if ( WindowState = wsMaximized ) and not ( fsCreating in FFormState ) then
  begin

noch Probleme hat, dann suche ich noch einmal :-D.

[DieDolly]

Zitat:

Zitat von Michael II (Beitrag 1428686)

Wenn ich den Code in VCL.Forms und VCL.Controls korrekt lese, dann tritt Activate vor Create auf, wenn WindowState=wsMaximized gesetzt wird, Scaled=TRUE belassen wird, mindestens Windows 6.3 installiert ist und wenn

Winapi.Windows.USER_DEFAULT_SCREEN_DPI <> GetCurrentPPIScreen( )

Bei meinem System:
Winapi.Windows.USER_DEFAULT_SCREEN_DPI 96
GetCurrentPPIScreen( ) 120

=> procedure TCustomForm.ScaleNormalSize(M, D: Integer); wird aufgerufen und damit, weil WindowState = wsMaximized dann irgendwann SetWindowPlacement(Handle, @WindowPlacement); => OnActivate


Falls jemand nach der Änderung (Code unten) (and not ( fsCreating in FFormState)

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if ( WindowState = wsMaximized ) and not ( fsCreating in FFormState ) then
  begin

noch Probleme hat, dann suche ich noch einmal :-D.

Habe es noch nicht getestet und wird schwer bei mir, weil ich den Fehler auch vorher nie hatte.
Aber einfach and not ( fsCreating in FFormState in der offiziellen Emba-Unit in TCustomForm.ScaleNormalSize einfügen und damit sollte es gut sein? Darf ich das als CE_Nutzer überhaupt? :lol:

[blawen]

Zitat:

Zitat von Michael II (Beitrag 1428686)

Falls jemand nach der Änderung (Code unten) (and not ( fsCreating in FFormState)

Delphi-Quellcode:

procedure TCustomForm.ScaleNormalSize(M, D: Integer);
var
  WindowPlacement: TWindowPlacement;
begin
  if ( WindowState = wsMaximized ) and not ( fsCreating in FFormState ) then
  begin

noch Probleme hat, dann suche ich noch einmal :-D.

Dies könnte es gewesen sein.
Testweise habe ich die 32-Bit VCL-Version neu kompiliert und das Minimalbeispiel mit zwei Formularen funktionierte bei meinem Testrechner (Laptop mit HD Auflösung) wie erwartet :-)

[DieDolly]

Wie pflegt man die Änderung ein? Einfach in die Unit schreiben, speichern und vorhandene Projekte bereinigen + kompilieren?

[Uwe Raabe]

Zitat:

Zitat von DieDolly (Beitrag 1428695)

Wie pflegt man die Änderung ein? Einfach in die Unit schreiben, speichern und vorhandene Projekte bereinigen + kompilieren?

Die Unit muss im Suchpfad des jeweiligen Projekts liegen. Der Delphi-Source-Folder gehört definitiv nicht dazu und darf es auch nicht.

In der Regel verwende ich für solche gepatchten Delphi Units entweder das Projektverzeichnis oder ein dediziertes Unterverzeichnis.

[DieDolly]

Dann lasse ich alles so wie es ist statt rumzufummeln und warte auf ein offizielles Update.
Denn irgendwann ist die gepatchte Unit auch wieder veraltet und nicht mehr up to date und dann hat man doppelte oder dreifache Arbeit.

[Bbommel]

Zitat:

Zitat von Michael II (Beitrag 1428686)

Falls jemand nach der Änderung (Code unten) (and not ( fsCreating in FFormState)

noch Probleme hat, dann suche ich noch einmal :-D.

Also bei mir funktioniert das so erst einmal. Ich hatte deinen Lösungsvorschlag daher auch schon im entsprechenden Ticket zu dem Bug im QP (hier: https://quality.embarcadero.com/browse/RSP-23179) gepostet, natürlich mit Verweis auf deinen Original-Post (will mich ja nicht mit fremden Federn schmücken).