Delphi 11 -GetSystemMetrics( SM_CXSIZEFRAME ) ermittelt andere Werte

[Michael II]

VCL

Mir ist in einer App (mit zugegeben etwas altem Code) aufgefallen, dass zur Laufzeit die Fenster nicht mehr ganz genau gleich positioniert werden wie vor Delphi 11.

Grund: Folgender Code meldet nach Klick auf Button1 bis und mit Delphi 10.4 (für mein System erwartet) für cxsizeframe 9 zurück, bei Delphi 11 4.

Delphi-Quellcode:

function cxsizeframe : integer;
begin
  Result := GetSystemMetrics(SM_CXSIZEFRAME);
end;


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

Weiss jemand wieso Delphi 11 hier einen anderen Wert ermittelt und damit das Verhalten von Anwendungen ändert?

Mir ist bewusst, dass ich Fenster anders positionieren kann/soll. Es interessiert mich aber, wieso Delphi 11 hier mit dem bisherigen Verhalten bricht.

[himitsu]

Hast du mal die Manifeste verglichen?

Kannst auch direkt in der EXE nachsehn, mit einem Ressourcen-Editor oder einem Texteditor (siehe

Delphi-Quellcode:

<assembly

).
Das ist ja eine bekannte Stelle, welche auch derartige APIs beeinflusst.



Bloß nicht wundern, dass es für Windows 11 keine neue supportedOS-ID gibt, denn hier gilt die von Windows 10 weiterhin.

[Michael II]

Besten Dank himitsu für den Tipp.

Ich habe eine "alte" App ins neue Delphi geladen und bin dabei aufs Problem gestossen. Ich nehme mal an, dass Delphi 11 das Manifest beim Laden nicht abgeändert hat.

Beim Testen mit obigem Minimalbeispiel habe ich's genau gleich getan.

Werde das mit dem Manifest in der exe aber natürlich mal prüfen - aber nicht mehr heute Nacht ;-).

[haentschman]

Moin...8-)
[OT]

Zitat:

TForm195

...du solltest dringed mal aufräumen.:stupid::zwinker:
[/OT]

[himitsu]

Keine Sorge, ab oberen 4-stellig fangen es erst die Problemchen mit dem Dateisystem Dateisystembetrachtungs-&Backupprogrammen an.

[Achim Kalwa]

Zitat:

Zitat von Michael II (Beitrag 1496533)

VCL
Grund: Folgender Code meldet nach Klick auf Button1 bis und mit Delphi 10.4 (für mein System erwartet) für cxsizeframe 9 zurück, bei Delphi 11 4.

Delphi-Quellcode:

function cxsizeframe : integer;
begin
  Result := GetSystemMetrics(SM_CXSIZEFRAME);
end;

...
Weiss jemand wieso Delphi 11 hier einen anderen Wert ermittelt und damit das Verhalten von Anwendungen ändert?

Ab Delphi gibt es zusätzlich zu Winapi.Windows.GetSystemMetrics() in der VCL eine gleichnamige function in TControl.GetSystemMetrics(), welche intern dann Winapi.Windows.GetSystemMetricsForDpi() aufruft, und zwar abhängig davon ob die Anwendung mit PerMonitorV2-Skalierung läuft.

Vergleiche mal die Ergebnisse von
Winapi.Windows.GetSystemMetrics(SM_CXSIZEFRAME)
und
(Self.)GetSystemMetrics(SM_CXSIZEFRAME);

Im Grunde ist das eine gute Idee, denn damit wird bestehender Code ohne Anpassung HighDPI-fähig. Warum SM_CXSIZEFRAME bei aktiver Skalierung nur noch 4 statt 9 ist, kann ich aber auch nicht erklären.

[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.

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1496558)

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. :gruebel:

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?

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1496562)

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.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1496564)

Zitat:

Zitat von venice2 (Beitrag 1496562)

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:

...

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.

[venice2]

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:

Zitat von Uwe Raabe (Beitrag 1496560)

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:

Zitat von Michael II (Beitrag 1496608)

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:

Zitat von Michael II (Beitrag 1496608)

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.

[BerndS]

Zitat:

...Anpassung seiner Anwendungen..

Da PE 6.0 z.B. auch die Höhe des Fenstertitels eines Toolwindows vergrößert, ist doch eine Anpassung der Vcl zu machen.
Ich wüsste jetzt nicht, wie ich das in der Anwendung berücksichtigen sollte.

[Uwe Raabe]

Zitat:

Zitat von BerndS (Beitrag 1496646)

Zitat:

...Anpassung seiner Anwendungen..

Da PE 6.0 z.B. auch die Höhe des Fenstertitels eines Toolwindows vergrößert, ist doch eine Anpassung der Vcl zu machen.
Ich wüsste jetzt nicht, wie ich das in der Anwendung berücksichtigen sollte.

Hab da gerade mal jemanden mit der Nase drauf gestupst.

[Michael II]

Hallo lieber Uwe,

Sorry für meine späte Reaktion. Besten Dank für all deine Abklärungen, Infos und fürs Gegentesten.

In einem Forum von microsoft steht auch was zu diesem Thema. Offenbar sollte man seit Jahren bei solchen "Randberechnungen" SM_CXPADDEDBORDER auch beachten; SM_CXSIZEFRAME allein genügte nur bis und mit Vista.

Damit erübrigt sich auch ein QP Eintrag: Delphi 11 macht's genau so wie es heutzutage sein sollte.

Bleibt also: Beim Umstieg auf Delphi 11: Eigenen Code überprüfen und allenfalls anpassen.
Bei "Randberechnung via GetSystemMetrics()":
Bis Delphi 10 reichte: GetSystemMetrics(SM_CXSIZEFRAME)
Bis Delphi 11: GetSystemMetrics(SM_CXSIZEFRAME) + GetSystemMetrics(SM_CXPADDEDBORDER)

Cool wäre dies: Du lädst ein altes Projekt in ein neues Delphi. Ein Tool prüft den Code auf bekannte Probleme und warnt dich.

Uns allen einen sonnigen Tag wünsch
Michael

[jaenicke]

Ich habe an der Stelle Glück, denn mir haben bisher immer ClientWidth und Width usw. gereicht. Direkt mit den Randinformationen musste ich deshalb gar nicht arbeiten.

Zitat:

Zitat von Michael II (Beitrag 1496669)

Damit erübrigt sich auch ein QP Eintrag: Delphi 11 macht's genau so wie es heutzutage sein sollte.

Das Problem wird ja ohnehin nicht von Delphi verursacht, sondern es geht um die Werte, die Windows basierend auf dem Manifest liefert. Und es wäre schlicht falsch, wenn Delphi in die Versionsinformationen nicht standardmäßig eintragen würde, dass die aktuelle Version von Windows, für die Delphi entwickelt wurde, unterstützt wird, sondern eine ältere nehmen würde.

[dummzeuch]

Zitat:

Zitat von Michael II (Beitrag 1496669)

Cool wäre: Du lädst ein Projekt in ein neues Delphi. Ein Tool prüft den Code auf Probleme wie dieses und warnt dich.

Ein Grep Search sollte sowas finden. Ist aber natürlich nicht automatisch.

[Michael II]

Zitat:

Zitat von jaenicke (Beitrag 1496670)

Ich habe an der Stelle Glück, denn mir haben bisher immer ClientWidth und Width usw. gereicht. Direkt mit den Randinformationen musste ich deshalb gar nicht arbeiten.

Steiles Glück ist immer das beste... ;-). Bei mir wars in einer Komponente fürs Skalieren von Fenstern unter Beibehaltung vom Seitenverhältnis (Dativ ist...) drin. Ich halte mich auch lieber am Glück fest und hab's ausgebaut.

Zitat:

Zitat von jaenicke (Beitrag 1496670)

Und es wäre schlicht falsch, wenn Delphi in die Versionsinformationen nicht standardmäßig eintragen würde, dass die aktuelle Version von Windows...

Völlig klar. Die Anpassung war ja nur fürs Testen, ob dort der Grund liegt.

[Uwe Raabe]

Wie zu erwarten ist das auch außerhalb des Delphiversums ein Problem: Why does Window geometry change when migrating from VS2010 to VS2017?
(Dank an Stefan Glienke für den Link)