Delphi 12, MDI Applikation und Flackern

[looseleaf]

Servus Robert!

Du bist mein Held. Wie bist du denn da darauf gekommen? Ich war schon in den Tiefen der VCL und hab die WM_ACTIVATE Messages verfolgt.
Ich geb ein digitales Bier aus

In deinem Link zum QC ist kein Resultat enthalten.

Zitat von rdeutsch:

Hallo Stefan

Wir sind aktuell in der gleichen Phase wie du. Wir migrieren von Delphi 11 auf Delphi 12 und habe den gleichen nervigen Effekt feststellen müssen.
Denke es hängt damit zusammen, dass Delphi 12 das Zeichnen der "rechteckigen" MDI-Child-Formular wahrscheinlich neu selbst übernimmt. Dies, wenn TStyleManager.ChangeChildFormSystemBorder auf True steht.

Wenn du in der Projektdatei TStyleManager.ChangeChildFormSystemBorder auf False setzt (VCL.Themes-Unit), dann erscheinen die MDI-Child-Forms zwar wieder im bisherigen Design, aber das Flackern ist weg.



Hoffe, dass dies im nächsten Update behoben ist.

Gruss, Robert

[Uwe Raabe]

Dieser Link sollte funktionieren: https://quality.embarcadero.com/browse/RSP-43487

[himitsu]

Konnte bei uns D12 noch nicht testen ... blöder ELC. (und niemand Zeit die Lizenz zu aktualisieren und von Alleine kann der ja garnichts machen)

Erstmal sollte auch die DCU neu kompiliert werden.
C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\buildrtl.bat
Wo ist das buildvcl?

Oder explizit gegen die PAS kompilieren.


Aber da wir mit Packages arbeiten und geänderte PAS/DCU somit niemanden interessieren, wäre es für uns eh keine Lösung.

[jaenicke]

Zitat von himitsu:

Aber da wir mit Packages arbeiten und geänderte PAS/DCU somit niemanden interessieren, wäre es für uns eh keine Lösung.

Du kannst auch einfach ClientWndProc in dem Formular überschreiben und dort bei WM_NCACTIVATE und der OS-Prüfung usw. analog nichts tun, ansonsten inherited. Das sollte den gleichen Effekt haben, ohne dass du in dem VCL-Quelltext etwas ändern muss.

[rdeutsch]

Zitat von jaenicke:

Zitat von himitsu:

Aber da wir mit Packages arbeiten und geänderte PAS/DCU somit niemanden interessieren, wäre es für uns eh keine Lösung.

Du kannst auch einfach ClientWndProc in dem Formular überschreiben und dort bei WM_NCACTIVATE und der OS-Prüfung usw. analog nichts tun, ansonsten inherited. Das sollte den gleichen Effekt haben, ohne dass du in dem VCL-Quelltext etwas ändern muss.

Danke dir für den Hinweis. Ist ganz klar die schönere Variante. Habs so angepasst und klappt, d.h. auch wenn TStyleManager.ChangeChildFormSystemBorder = True ist, wird kein unerwünschter Repaint beim Öffnen eines MDI-Childs ausgelöst. Alles bleibt ruhig.
Aber was mich im Moment noch stört, ist dass sobald ein MDI-Child geschlossen wird, trotzdem immer noch ein Repaint stattfindet und dieses unerwünschte Flickering auslöst.

Hat hierzu jemand einen Tipp wie man dies unterbinden könnte?

Danke.

[SWeb]

Ich habe leider feststellen müssen, dass das Thema "Flackern" seit Delphi 12 wieder relevant ist.
Bei RDP Zugriffen auf VM-gehostete Anwendungen tritt der Flicker-Effekt z.B. wieder bei den Tabs von TAdvOfficePager auf.
(-> https://support.tmssoftware.com/t/ta...r-tabs-flicker)

Der Workaround:

Application.SingleBufferingInRemoteSessions := False;

funktioniert zwar, aber das kann doch keine endgültige Lösung sein, diesen Eintrag bei allen Anwendungen auf Verdacht nachzupflegen.

Welche anderen Auswirkungen hat SingleBufferingInRemoteSessions?
Das habe ich noch nicht herausgefunden

Muss hier TMS etwas machen, damit das wieder mit Defaulteinstellungen funktioniert oder Embarcadero?

[Delphi.Narium]

Funktioniert eventuell

Delphi-Quellcode:

if Application.InRemoteSession then
  Application.SingleBufferingInRemoteSessions := False;

oder
Application.SingleBufferingInRemoteSessions := not Application.InRemoteSession;

[Uwe Raabe]

Zitat von SWeb:

Muss hier TMS etwas machen, damit das wieder mit Defaulteinstellungen funktioniert oder Embarcadero?

Wenn man mal den Docwiki-Eintrag zu diesem Thema liest, dann liegt der Ball im Fall des TAdvOfficePager wohl eher bei TMS als bei Embarcadero. Insbesondere dieser Abschnitt legt das nahe:

Zitat:

For themed controls and style hooks, code should only use double buffering if this evaluates to True:

DoubleBuffered and (not InRemoteSession or not SingleBufferingInRemoteSessions)

In other words, the control is set to use double buffering whether you are running in a local session, or you are in a remote session but the application developer wants double-buffering regardless.

Offenbar werden die beiden RemoteSession-Properties im betroffenen Control überhaupt nicht beachtet.

Erschwerend kommt wohl auch noch hinzu, dass sich das Control schon generell bezüglich DoubleBuffered unter Windows 11 anders verhält als unter Windows 10.