none
Zoom Funktion von Windows 7 RRS feed

  • Frage

  • Hallo Forum

    Ich habe jetzt doch tatsächlich mal Win7 organisiert und getestet, ob meine gute alte Software (unter VC++ 6.0 SP6 erstellt) dort auch noch läuft. Erfreulicherweise tut sie das, allerdings mit ein paar optischen Unsauberkeiten:

    Die Zoom Funktion von Windows 7 (ALLES auf 100%, 125% oder 150% aufblasen) funktioniert bei den Icon-Draw Funktionen, bei allen BitBlt-Funktionen von Bitmaps etc. eigentlich nicht, d.h. manche Objekte sind größer und manche eben nicht.

    Gibt's da bessere Erkenntnisse? Gibt es "Tricks", die ich nicht mehr verwenden darf, bzw. welche die ich verwenden muss, damit das Ganze auch nach etwas gleich sieht?

     

    Grüße

    FireHeart

     

    Montag, 26. Juli 2010 12:45

Antworten

  • >Hallo Bordon Jetzt bin ich aber schon von Win7 enttäuscht. Soll das etwa heißen, ich muss mich selber um die Skalierung meiner Anwendung kümmern?

    Das ist nach meinem Wissensstand noch (immer) so. Ich kümmere mich um die korrekte Skalierung in meinen Anwendungen selber, und verwende dafür die Werte aus den Funktionen "GetSystemMetrics" und  "SystemParametersInfo", so wie ich es in meinem Eingangsposting beschrieben habe.

    >Ich hätte wohl gedacht, dass Win7 einfach über den Grafiktreiber alles größer macht und die Anwendung selber damit gar nichts am Hut hätte.... Ich kenne das Problem schon mit der Einführung von WinXP.

    Nun das von Dir genannte "Problem" gibt es schon mindestens seit Windows 2000 vielleicht sogar NT4, da bin ich mir aber nicht sicher. Wenn Du bei Windows 2000 / XP in den Darstellungs Optionen im "Classic" die Schemata mit der Option "Groß/large" oder "Extra groß/extra large" verwendest mußt Du auch schon selber anpassen.

    Wie ich schon sagte wirst Du mit diesem API Funktionen ans Ziel kommen. Wenn Du noch die Botschaft WM_SETTINGCHANGE mit auswertest, kannst Du unter Windows 2000 / XP / (Vista?) die Einstellungen "on the fly" korrigieren. Bei Windows 7 reicht es während der Anwendungs Initialisierung, da die Zoom Einstellung nicht mehr "on the fly" geändert werden kann wie bei Windows 2000 / XP / (Vista?).

    Aber mal im Ernst, wie soll Windows das ganze alles selber umskalieren? Woher soll das System denn wissen, dass alle Controls skaliert werden sollen oder bestimmte nicht. Wenn Du noch mit GDI Funktionen auf Deinem Fenster was zeichnest wird es noch komplizierter, wie soll Windows das noch selber umskalieren, und vor allem wissen das das eine umskaliert werden soll, und evtl. andere Zeichnenoperationen nicht. Das kannst nur Du als Entwickler wissen.

    • Als Antwort markiert Fire-Heart Mittwoch, 28. Juli 2010 05:34
    Dienstag, 27. Juli 2010 08:19

Alle Antworten

  • Hallo FireHeart

    Von der Funktion sollte die Zoom Funktion identisch sein mit der W2K/XP Einstellung in den Farbschema in der Form "Normal",  "Groß" und "extra groß". Du solltes Deine Anwendung mal spasseshalber unter z.B. XP in der Darstellung "Extra Groß" testen. Ich wage zu behaupten, dass da Deine Anwendung auch auf die Nase fällt.

    Zur Lösung des Problemes würde ich die Funktion "GetSystemMetrics" verwenden. Es würde z.B. mit dem Wert "SM_CYCAPTION" die Höhe der Fensterleiste zurückgeliefert werden. Anhand dieses Wertes kannst Du händisch in Deinem Programm die falsch gezeichneten Dinge korrekt skalieren und entsprechend größer oder kleiner zeichen.

    Du könntest aber ebenso mit der Funktion "SystemParametersInfo" und dem Wert "SPI_GETNONCLIENTMETRICS" die Fonteigenschaften des Captionfonts als Grundlage verwenden.

    Beide von mir genannte Funktionen bieten Dir eine gute Möglichkeit herauszufinden, wie Dein Windows gerade konfiguriert ist, bzw. was der Anwender so verstellt hat.

     

    Gruß

     

    Bordon

    Montag, 26. Juli 2010 16:45
  • Hallo Bordon Jetzt bin ich aber schon von Win7 enttäuscht. Soll das etwa heißen, ich muss mich selber um die Skalierung meiner Anwendung kümmern? Ich hätte wohl gedacht, dass Win7 einfach über den Grafiktreiber alles größer macht und die Anwendung selber damit gar nichts am Hut hätte.... Ich kenne das Problem schon mit der Einführung von WinXP. Unter WinNT war die Caption-Leiste immer gleich groß und mein Hauptfenster konnte eine fixe Größe haben. Dann kam WinXP mit variablen - und vor allem größeren Caption-Leisten und schon hatte mir XP einfach noch einen Scrollbar in mein Fenster gesetzt. Da ich diesen jedoch nicht erwartet hatte, konnte man gewisse Teile damit scrollen und die anderen nicht ... entsprechend war das Ergebnis. Grüße FireHeart
    Dienstag, 27. Juli 2010 06:47
  • >Hallo Bordon Jetzt bin ich aber schon von Win7 enttäuscht. Soll das etwa heißen, ich muss mich selber um die Skalierung meiner Anwendung kümmern?

    Das ist nach meinem Wissensstand noch (immer) so. Ich kümmere mich um die korrekte Skalierung in meinen Anwendungen selber, und verwende dafür die Werte aus den Funktionen "GetSystemMetrics" und  "SystemParametersInfo", so wie ich es in meinem Eingangsposting beschrieben habe.

    >Ich hätte wohl gedacht, dass Win7 einfach über den Grafiktreiber alles größer macht und die Anwendung selber damit gar nichts am Hut hätte.... Ich kenne das Problem schon mit der Einführung von WinXP.

    Nun das von Dir genannte "Problem" gibt es schon mindestens seit Windows 2000 vielleicht sogar NT4, da bin ich mir aber nicht sicher. Wenn Du bei Windows 2000 / XP in den Darstellungs Optionen im "Classic" die Schemata mit der Option "Groß/large" oder "Extra groß/extra large" verwendest mußt Du auch schon selber anpassen.

    Wie ich schon sagte wirst Du mit diesem API Funktionen ans Ziel kommen. Wenn Du noch die Botschaft WM_SETTINGCHANGE mit auswertest, kannst Du unter Windows 2000 / XP / (Vista?) die Einstellungen "on the fly" korrigieren. Bei Windows 7 reicht es während der Anwendungs Initialisierung, da die Zoom Einstellung nicht mehr "on the fly" geändert werden kann wie bei Windows 2000 / XP / (Vista?).

    Aber mal im Ernst, wie soll Windows das ganze alles selber umskalieren? Woher soll das System denn wissen, dass alle Controls skaliert werden sollen oder bestimmte nicht. Wenn Du noch mit GDI Funktionen auf Deinem Fenster was zeichnest wird es noch komplizierter, wie soll Windows das noch selber umskalieren, und vor allem wissen das das eine umskaliert werden soll, und evtl. andere Zeichnenoperationen nicht. Das kannst nur Du als Entwickler wissen.

    • Als Antwort markiert Fire-Heart Mittwoch, 28. Juli 2010 05:34
    Dienstag, 27. Juli 2010 08:19
  • Mal Grundsätzlich:
    Windows skaliert hier gar nichts. Das was Du als Skallieren wahrnimmst sind nur die unterschieldichen Dialog Font Größen und die damit verbundene andere Umrechnung von DLUs (Dialog Base Units) in Pixel.
    Weiterhin wird festgelegt, was die Standard-Icon Größe ist und auch die kann sich eben ändern (32x32 oder 48x48)...

    Ein Pixel bei einem BitBlt bleibt ein Pixel...


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Dienstag, 27. Juli 2010 10:45
    Moderator
  • Hallo Martin Ich hätte mir das eher so vorgestellt wie die Bildschirmauflösung bei einem CRT Monitor. Wenn ich von 1024x768 auf 800x600 runtergehe, dann werden alle Objekte größer...ohne dass dies die Anwendung nur im Geringsten betrifft...für Leute, die schon schlecht sehen ist das eigentlich die Lösung. Wenn ich jetzt jedes Objekt in einer anderen "native" Auflösung anbieten können muss, nur damit ich verschiedene Größen jeweils in einem native Objekt anbieten kann...dann ist das eigentlich schon eher zum Selbstzweck.... Interessanterweise hab ich allerdings festgestellt, dass gewisse Objekte, die ich dynamisch in einen Dialog einblende auch bei 100% Windows Skalierung woanders (nämlich falsch) liegen als unter WinXP. Das muss ich allerdings noch genauer untersuchen. Ich habe zudem das Problem, dass ich (aus Kompatibilitätsgründen) noch unter VC++ 6.x arbeite und dadurch aber leider nicht gleich am Win7 Arbeitsplatz entwickeln kann, weil Win7 und VC6 nicht mehr tut. Grüße FireHeart
    Mittwoch, 28. Juli 2010 05:40
  • >Wenn ich von 1024x768 auf 800x600 runtergehe, dann werden alle Objekte größer...ohne dass dies die Anwendung nur im Geringsten betrifft...für Leute, die schon schlecht sehen ist das eigentlich die Lösung.

    Die Objekte erscheinen nur größer auf einem CRT weil Du alle Bildschirmauflösungen auf der Bildschirmdiagonalge abbildest. Das ist bei LCDs halt anders. Da erscheint ein z.B. 32x32 Pixel Icon unter 800x600 größer als unter 1024x768....

    >Wenn ich jetzt jedes Objekt in einer anderen "native" Auflösung anbieten können muss, nur damit ich verschiedene Größen jeweils in einem native Objekt anbieten kann...dann ist das eigentlich schon eher zum Selbstzweck.... Interessanterweise hab ich allerdings festgestellt, dass gewisse Objekte, die ich dynamisch in einen Dialog einblende auch bei 100% Windows Skalierung woanders (nämlich falsch) liegen als unter WinXP. Das muss ich allerdings noch genauer untersuchen.

    Ist das Problem unter XP auch im Classic Schema? Hast Du ein Manifest eingebunden? Der einfachste Weg wäre einfach kein Manifest in der Anwenung verwenden. Dann sieht die zwar aus wie zu den guten alten Windows NT/2000 Zeiten, aber alles sollte am richtigen Platz sein.

    >Ich habe zudem das Problem, dass ich (aus Kompatibilitätsgründen) noch unter VC++ 6.x arbeite und dadurch aber leider nicht gleich am Win7 Arbeitsplatz entwickeln kann, weil Win7 und VC6 nicht mehr tut.

    Bist Du Dir sicher mit VC6 unter Windows 7. Unter Vista 32 Bit tut VC6 mit kleinen Einschränkungen. Ich meine mich zu erinnern, dass nicht alle Variablen unter allen Bedingungen beim Debuggen angezeigt wurden. Zur Not könnte man VC6 unter Windows 7 in einer VM laufen lassen. Wobei ich Dir nur den Ratschlag geben kann auf eine neue Entwicklungsumgebung zu switchen, obwohl ich ein Fan des (inzwischen total veralteten) VC6 bin / war. Ich bin mit VC2008 zufrieden, und werde sogar jetzt langsam auf 2010 umstellen...

     

    Mittwoch, 28. Juli 2010 07:07
  • 1. VC6 und Windows 7 vertagen sich sehr wohl.
    2. Gibt es virtuelle Maschinen (in denen man auch entwickeln kann)
    3. DLUs und Pixel sind was anderes. Wenn Du dynamisch in einem Dialog etwas erzeugst, dann solltest Du seine Position in DLUs besimmne. Ich setzemeistens einen Platzhalter (ein verborgenes Static) dessen Koordinaten ich bestimme und danach zerstöre.
    Oder ich benutze relative Koordinaten zu bestehenden Controls. (z.B. 10 Pixel unter, rechts von A, bis 10 pixel über, links von B)

    Eine solche Skalierung wie Du sie vorschlägst würde zur Verrasterung der Anwedung führen.
    Der Weg der hier gegabgen wird ist schon OK, und High DPI gibt es seit Windows 98, nur es hat keinen Entwickler gekümmert weil die nämlich keine MSDN und Doku lesen. SCNR
    Der Aufwand ist so groß nämlich nicht.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Mittwoch, 28. Juli 2010 07:09
    Moderator
  • Da es hier gerade besprochen wird:

    Wie löst man dies bei Bitmaps auf einen Dialog? Also einem im Resourceeditor angelegten Dialog. Wie ich gesehen habe, werden diese auch nicht mit skaliert, obwohl dies für den Rest des Dialoges klappt.
    Wenn ich das obige richtig verstehe, dann muss man diese am besten direkt entfernen und darf nur einen Platzhalter auf den Dialog setzen (um die Bitmaps dann dort in passender Größe einzufügen), oder gibt es da doch eine Möglichkeit diese Bitmaps auch passend mit dem Rest des Dialoges zu skalieren?

    Gruß


    - Florian

    Donnerstag, 4. Juli 2013 13:20
  • Mal Grundsätzlich:
    Windows skaliert hier gar nichts.

    Ab Vista skaliert Windows sehr wohl automatisch. Wenn Du das nicht willst, musst Du aktiv eingreifen und diesen Mechanismus abschalten. Aber da das Ergebnis der automatischen Skalierung nicht so überzeugend ist, macht man das wohl so ziemlich immer.  :-)

    Writing High-DPI Win32 Applications

    Zitat: "Windows Vista introduces a feature called DPI virtualization, which provides some level of automatic scaling support to applications that are not DPI-aware."

    Samstag, 6. Juli 2013 08:50
  • Wie löst man dies bei Bitmaps auf einen Dialog? Also einem im Resourceeditor angelegten Dialog. Wie ich gesehen habe, werden diese auch nicht mit skaliert, obwohl dies für den Rest des Dialoges klappt.

    Suchst Du vielleicht SS_REALSIZECONTROL?

    Siehe: Static Control Styles

    Samstag, 6. Juli 2013 09:02
  • Danke Rene,

    das sieht mir genau richtig aus. Leider kann man das Flag wohl nicht im Resourceeditor setzen, hab zumindest nix passendes gefunden. Nach der Änderungen in der RC-Datei ist komischerweise im Resourceeditor "Real Size Image" auf true, wenn man dieses im Resourceeditor setzt hat es allerdings einen anderen Effekt (SS_REALSIZEIMAGE wird gesetzt) - keine Ahnung ob das für alle VS Versionen gilt oder nur bei VS 2010.

    SS_CENTERIMAGE muss dann ggfls. noch entfernt werden, sonst wird das Bitmap einfach nur zentriert.


    - Florian

    Montag, 8. Juli 2013 08:22