Delphi 11 -GetSystemMetrics( SM_CXSIZEFRAME ) ermittelt andere Werte

[Michael II]

Hallo alle...

danke fürs Feedback; natürlich auch für die wertvollen Tipps, wie ich meine Platte besser füllen soll .

Ich habe die beiden "Exes" geöffnet, die Manifeste extrahiert und vergleichen lassen. Resultat: "Die zwei Texte sind völlig gleich."

Danke für den Vorschlag, GetSystemMetrics() von VCL.Controls und von Winapi.Windows zu nutzen. Das macht der Code in #1 bereits.

Delphi-Quellcode:

procedure TForm195.Button1Click(Sender: TObject);
begin
  Showmessage( GetSystemMetrics(SM_CXSIZEFRAME).ToString + #10 + // VCL.Controls
               cxsizeframe.ToString ); // Winapi.Windows
end;

function cxsizeframe : integer; (siehe #1) nutzt Winapi.Windows. Bei Delphi 10.4 gibt cxsizeframe noch 9 zurück, bei Delphi 11 nun 4.

GetSystemMetrics() von VCL.Controls gibt bei D10.4 und D11 4 zurück.

Ich weiss immer noch nicht was den Unterschied ausmacht.
Wahrscheinlich rechnen D10.4 und D11 irgendwie richtig...

Wer noch Code mit GetSystemMetrics(SM_CXSIZEFRAME) aus der Winapi.Windows nutzt, muss nach dem Umstieg auf Delphi 11 die Fenster eventuell auch anders/neu positionieren.

[venice2]

Zitat:

Wer noch Code mit GetSystemMetrics(SM_CXSIZEFRAME) aus der Winapi.Windows nutzt, muss nach dem Umstieg auf Delphi 11 die Fenster eventuell auch anders/neu positionieren.

Dann ist es ein Fehler von Delphi 11.
Ein Betriebssystem bzw. die API der jeweiligen Funktion von diesen) gibt die Breite des Borders vor und wenn ein Programm in dem fall Delphi von der Norm abweicht ist es schlichtweg Falsch.

Wenn ich mein Fenster (nonVcl) mit Delphi kompiliere dann hat mir Delphi die Werte zur Verfügung zu stellen die dem Betriebssystem entsprechen.
Und zwar diese aus der WinApi nix anderes.

Wo kommen wir da hin wenn jede Programmiersprache sein eigenes Süppchen kocht.

Delphi-Quellcode:

        if IsWindowVisible(GetDlgItem(WinHandle, ID_MAXIMIZE)) then
        begin
          GetClientRect(WinHandle, rc);

          xF := rc.Right;
          yF := rc.Bottom;
          xSide := 0;
          BORDER := GetSystemMetrics(SM_CXFRAME); // SM_CXSIZEFRAME ist das gleiche
          if ((P.X >= xF - BORDER) and ((P.Y >= yF - BORDER))) then
          begin
            HITTEST := HTBOTTOMRIGHT;
          end

Ich muß mich darauf verlassen das die Koordinaten bzw. Border mir die richtigen Werte aus der WinApi zurück gibt.
Die dürfen vom Delphi Compiler nicht verändert werden.

Sollte es jedoch nur die Fenster in der IDE von Delphi betreffen kann es mir egal sein was die da rummurksen.

EDIT:
Es sollte nicht die Aufgabe einer Programmiersprache sein eine Anwendung High DPI fähig zu machen.
Das unterliegt dem Programmierer und zwar mit Altbewährten Methoden unter Verwendung der vom System bereitgestellten API.

[Uwe Raabe]

TControl.GetSystemMetrics verwendet die DPI-konforme Version GetSystemMetricsForDPI wenn die Anwendung als Per Monitor V2 aware läuft, ansonsten die normale GetSystemMetrics Version. Dies entspricht der Empfehlung in der Windows Dokumentation zu GetSystemMetrics:

Zitat:

This API is not DPI aware, and should not be used if the calling thread is per-monitor DPI aware. For the DPI-aware version of this API, see GetSystemMetricsForDPI.

Delphi liefert da also exakt die Werte zurück, die Windows bei der jeweiligen Funktion zurückliefert. Umgerechnet wird da gar nichts.

Wenn also Windows.GetSystemMetrics und TControl.GetSystemMetrics unterschiedliche Werte liefern, dann weil die Anwendung sich als Per Monitor V2 aware registriert. In dem Fall ist aber der Aufruf von Windows.GetSystemMetrics schlichtweg falsch. Microsoft schweigt sich auch aus, wie die Rückgaben von Windows.GetSystemMetric bei solch falscher Verwendung aussehen. Das kann vom Windows-Build oder auch von der Skalierung des Monitors abhängen, auf dem das abfragende Control gerade dargestellt wird.

In jedem Fall liefert aber TControl.GetSystemMetrics den korrekten Wert und ist demnach vorzuziehen.

Ich gehe mal davon aus, dass sowohl die Delphi 10.4 als auch die Delphi 11 Exe auf demselben Windows und demselben Monitor gestartet wurden. Andernfalls wären Unterschiede durchaus zu erwarten.

[Michael II]

Zitat von Uwe Raabe:

Wenn also Windows.GetSystemMetrics und TControl.GetSystemMetrics unterschiedliche Werte liefern, dann weil die Anwendung sich als Per Monitor V2 aware registriert. In dem Fall ist aber der Aufruf von Windows.GetSystemMetrics schlichtweg falsch.

Besten Dank für die microsoft Info/Warnung.

Wie bereits erwähnt: Es ist mittlerweile ausgebauter Uraltcode, welcher seit Delphi 2 "gepflegt" wird und bis Delphi 10.4 Update 2 in diesem Bereich problemlos lief. Bis da war mir kein Fall bekannt, in welchem beim Aufruf der WinApi Funktion ein Problem aufgetreten ist. (Das Programm wurde bis jetzt auf über 44'000 voneinander verschiedenen Windows Kisten (auch mit Monitoren mit enormer Auflösung) installiert. Bis vor Delphi 11 gab es kein negatives Feedback.) Wenn du mir ein Gegenbeispiel hast, dann sehr gern.

Aber ich bin natürlich deiner Meinung: Wenn microsoft das empfiehlt, dann sollte man microsofts Vorschlag folgen. Delphi macht die Unterscheidung korrekt mittels Vcl.Controls.CheckPerMonitorV2SupportForWindow.

Aber:
Wenn ich in Delphi unter Projekt > Optionen > Manifest > DPI-Unterstützung die drei Fälle "Keine", "Monitor" und "Monitor V2" teste, dann erhalte ich diese Werte für GetSystemMetrics(SM_CXSIZEFRAME):

Delphi 10.4 Update 2

Keine 8 breiter Fensterrand VCL meldet 8 WIN meldet 8
Monitor 9 breiter Rand VCL:9 WIN:9
Monitor V2 9 breiter Rand VCL:4 WIN:9

Delphi 11
Keine 8 breiter Rand VCL:4 WIN:4
Monitor 9 breiter Rand VCL:4 WIN:4
Monitor V2 9 breiter Rand VCL:4 WIN:4

Beim Testen fällt auf:
- Bei Delphi 10.4 wird beim Winapi Aufruf von GetSystemMetrics(SM_CXSIZEFRAME) immer die "Fensterrandbreite" gemeldet.
- Die VCL Version meldet in den beiden Fällen "Keine" und "Monitor" ab Delphi 11 andere Werte. Die VCL Version liefert in Delphi 11 in keinem der Fälle die "Randbreite".
- Die Winapi Version meldet ab Delphi 11 in allen drei Fällen (Keine, Monitor, Monitor2) andere Werte.

Für andere Windows Skalierungen ähnlich.
______________________

Wenn wir zusätzlich die Werte von GetSystemMetrics(SM_CXPADDEDBORDER) betrachten, dann gilt:

Delphi 10.4 Update 2
Keine 8 VCL:8 0 WIN:8 0
Monitor 9 VCL:9 0 WIN:9 0
Monitor V2 9 VCL:4 5 WIN:9 0

Delphi 11
Keine 8 VCL:4 4 WIN:4 4
Monitor 9 VCL:4 5 WIN:4 5
Monitor V2 9 VCL:4 5 WIN:4 5


Wer also noch alten Code rumliegen hat, in welchem GetSystemMetrics(SM_CXSIZEFRAME) drin steht, sollte natürlich die VCL Version verwenden [Den Winapi Werten kann man nach Wechsel der Windows Skalierung kurz nicht trauen und laut m$ (siehe Info UR) gar nicht] und u.U. beim Wechsel auf Delphi 11 prüfen, ob auch GetSystemMetrics(SM_CXPADDEDBORDER) berücksichtigt worden ist.


Wieso rechnet Delphi 11 anders als Delphi 10.4 Update 2? Es liegt wohl an Projekt > Optionen > Erzeugen > Delphi Compiler > Linken > Untersystem Versionsfelder in PE Header. In Delphi 11 5.0 statt 6.0. setzen und Delphi 11 rechnet wie früher. (Dies ist natürlich keine Empfehlung... )

[Uwe Raabe]

Zitat von Michael II:

In Delphi 11 5.0 statt 6.0. setzen und Delphi 11 rechnet wie früher.

Interessant. Damit wird eigentlich die minimale Windows-Version festgelegt, mit der die EXE gestartet werden kann. Dabei entspricht 5.0 dem guten alten Windows 2000, die 6.0 wäre dann Windows Vista. Mir ist nicht bekannt, dass sich das irgendwie auf die SystemMetrics auswirkt.

Vielleicht solltest du dazu einen QP-Eintrag aufmachen. Beispielcode und einen (magischen) Workaround gibt es ja. Ich werde dann mal jemanden antriggern, der das mal hinterfragen kann.

[Uwe Raabe]

Zitat von Michael II:

Es liegt wohl an Projekt > Optionen > Erzeugen > Delphi Compiler > Linken > Untersystem Versionsfelder in PE Header. In Delphi 11 5.0 statt 6.0. setzen und Delphi 11 rechnet wie früher.

Ich habe das mal auf ein simples Konsolenprogramm heruntergebrochen:

Delphi-Quellcode:

program TestSystemMetrics;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  Winapi.Windows;

begin
  try
    Writeln(GetSystemMetrics(SM_CXSIZEFRAME).ToString);
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

Unter Delphi 10.4.2 wird hier 8 ausgegeben, während Delphi 11 eine 4 ausspuckt.

Die Änderung des besagten PE-Eintrags von 6.0 auf 5.0 in Delphi 11 ergibt dann in der Tat eine 8, während eine Änderung von 5.0 auf 6.0 das Ergebnis in Delphi 10.4.2 erwartungsgemäß auf 4 ändert.

Da es sich um eine Konsolenanwendung ohne eingebundene Resource und somit auch ohne Manifest handelt, fällt auch die DPI-Awareness als Beteiligte aus.

Erklären kann ich dieses Verhalten nicht und eine Dokumentation dafür konnte ich auch nicht finden. Es ist aber vermutlich schon seit einigen Delphi-Versionen so. Auf die Schnelle ließ sich das hier auch mit Delphi 10.1 Berlin reproduzieren.

[Uwe Raabe]

Den gleichen Effekt kann man übrigens auch erreichen, wenn man im Eigenschaften-Dialog des Windows-Explorers für die Exe (mit PE 5.0 compiliert) den Kompatibilitätsmodus aktiviert. Dann wird aus der 8 auch plötzlich eine 4.

[Uwe Raabe]

Informelle Aussage seitens Embarcadero: Die Einstellung bleibt auch in Zukunft auf 6.0!

Da dieses Problem ja auch vom Anwender selbst durch Aktivierung des Kompatibilitätsmodus forciert werden kann, wird man an eine Anpassung seiner Anwendungen an dieses Verhalten mittelfristig wohl nicht herum kommen.

[Uwe Raabe]

Zitat von venice2:

Es sollte nicht die Aufgabe einer Programmiersprache sein eine Anwendung High DPI fähig zu machen.
Das unterliegt dem Programmierer und zwar mit Altbewährten Methoden unter Verwendung der vom System bereitgestellten API.

Da bin ich aber vollkommen anderer Meinung. Zum einen ist es nicht die Programmiersprache, die hier die High-DPI Funktionalität zur Verfügung stellt, sonder das verwendete GUI-Framework (VCL), und zum anderen sehe ich genau diese Unterstützung des Frameworks als mittlerweile zu erwartendes Feature an. Wenn jemand das Framework nicht benutzen möchte ist ihm das natürlich unbenommen. Darunter fällt aber nur eine Minderheit der Delphi Entwickler.

[venice2]

Zitat:

Da bin ich aber vollkommen anderer Meinung.

Deshalb funktioniert es auch so reibungslos wie man hier an verschiedenen stellen entnehmen kann.

Wie viele Themen mit ähnlichen Probleme habe ich hier schon gelesen High DPI entsprechend.

Gibt es unter VS unterschiedliche Versionen einmal für DPI und andersrum? Denke mal nicht.
Warum wohl?

Richtig weil der Programmierer für das Aussehen und der Berechnung seiner Fenster alleine Verantwortlich ist.

Code:

long dpi(IN long nPix) {
    static float ratio;
    if (ratio == 0) {
        HDC hDC = GetDC(0); ratio = (GetDeviceCaps(hDC, LOGPIXELSX) / 96.0f); ReleaseDC(0, hDC); 
    }
    return  (long)(nPix * ratio);
}
//...
SetRect(&rc, 0, 0, dpi(XXX), dpi(YYY));

Dafür benötige ich keine extra VS High DPI Programmierumgebung das macht man von Hand. Kann das niemand mehr?

EDIT:
Hast du mal die Methode gelesen die ich verlinkt habe?
Dürfte doch für einen versierten Programmierer wie dich kein Problem sein das auf eine normale Form umzusetzen ohne das die VCL dir alles vorkaut.
Das verwirrt doch mehr als das es Hilft!

Wieviel Komponenten bauen auf der VCL auf? bzgl. (Darunter fällt aber nur eine Minderheit der Delphi Entwickler.)
Überdenke deine Meinung noch mal.
FAZIT:
Die VCL entwickelt sich immer mehr zu einem Fertigbauhaus System anliefern zusammenklopfen und fertig.
Kann eigentlich noch jemand irgend etwas selbst Programmieren?