Delphi 11 -GetSystemMetrics( SM_CXSIZEFRAME ) ermittelt andere Werte

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.

markieren

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?

**Uwe Raabe**

Zitat von venice2:

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.

Lieber verwende ich meine Zeit dafür, die VCL in diesem Punkt besser zu machen, damit auch andere Entwickler davon profitieren können.

Zitat von Uwe Raabe:

Zitat von venice2:

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.

Lieber verwende ich meine Zeit dafür, die VCL in diesem Punkt besser zu machen, damit auch andere Entwickler davon profitieren können.

Das Ehrt dich! Danke auch wenn ich sie nicht benötige.

Destotrotz scheint mir alles unfertig zu sein von den Styles angefangen bis hin zu High DPI.

Ja. Ich bin ein ganz kleines Licht aber das ist meine Meinung.

**ULIK**

[QUOTE=venice2;1496562]

Zitat:

...

markieren

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?

Nur mal so bemerkt: Dir ist aber schon bewußt, daß auf einem Multimonitorsystem und DPI Awareness V2, GetDeviceCaps ebenfalls mit Vorsicht zu genießen ist? Hier einmal ein Auszug aus der MS-Doku:

Zitat:

On a multiple monitor system, if hdc is the desktop, GetDeviceCaps returns the capabilities of the primary monitor. If you want info for other monitors, you must use the multi-monitor APIs or CreateDC to get a HDC for the device context (DC) of a specific monitor.

Zitat:

daß auf einem Multimonitorsystem und DPI Awareness V2

Ja. Es war nur ein Beispiel Auszug aus meinem KVPlayer64 (c++) der ist auf ein Multimonitorsystem nicht ausgelegt.
Meistens nutzen ich den in Delphi geschriebenen.

Das wäre aber ohne weiteres jederzeit Nachrüstbar falls ich jemals mit mehr als einen Monitor Arbeiten sollte.
Denke aber eher nicht.

**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:

zusammenfalten · markieren

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.