Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DPI (96, 120, etc.) von VB6 aus abfragen
784 views
Skip to first unread message
Hermie
Mar 7, 2012, 3:00:56 AM3/7/12
to
Hallo!
In der Systemsteuerung kann ich ja DPI ändern.
Ich schaffe es aber nicht, diesen Wert von VB6 aus abzufragen.
Ich habe bisher Folgendes probiert (diese Einstellungen ändern sich aber
nicht mit der DPI-Änderung):
1)
Screen.TwipsPerPixelX, bzw. Screen.TwipsPerPixelY
2)
Private Function GetDPI() As Long
Dim hWndDesk As Long
Dim hDCDesk As Long
Dim r As Long
hWndDesk = GetDesktopWindow()
hDCDesk = GetDC(hWndDesk)
Dim l&
l = GetDeviceCaps(hDCDesk, 88) 'LOGPIXELSX
r = ReleaseDC(hWndDesk, hDCDesk)
GetDPI = l
End Function
Gibt es noch etwas Anderes, oder mache ich etwas falsch?
Danke.
Gruß,
Hermann
In der Systemsteuerung kann ich ja DPI ändern.
Ich schaffe es aber nicht, diesen Wert von VB6 aus abzufragen.
Ich habe bisher Folgendes probiert (diese Einstellungen ändern sich aber
nicht mit der DPI-Änderung):
1)
Screen.TwipsPerPixelX, bzw. Screen.TwipsPerPixelY
2)
Private Function GetDPI() As Long
Dim hWndDesk As Long
Dim hDCDesk As Long
Dim r As Long
hWndDesk = GetDesktopWindow()
hDCDesk = GetDC(hWndDesk)
Dim l&
l = GetDeviceCaps(hDCDesk, 88) 'LOGPIXELSX
r = ReleaseDC(hWndDesk, hDCDesk)
GetDPI = l
End Function
Gibt es noch etwas Anderes, oder mache ich etwas falsch?
Danke.
Gruß,
Hermann
Martin KoWi
Mar 7, 2012, 3:24:29 AM3/7/12
to
Moin,
Du brauchst ein manifest mit:
<dpiAware>true</dpiAware>
Das Thema ist komplexer als man denkt, such mal nach "DPI-virtualization"
gruß, martin.
Du brauchst ein manifest mit:
<dpiAware>true</dpiAware>
Das Thema ist komplexer als man denkt, such mal nach "DPI-virtualization"
gruß, martin.
Helmut_Meukel
Mar 7, 2012, 3:51:39 AM3/7/12
to
Nach längere Bedenkzeit hat Hermie geschrieben:
Die Angabe der Betriebssystemversion wäre hilfreich.
Ich hab's noch nicht mit neueren Versionen probiert, aber bei NT4.0 und
Win2000 funktioniert 1).
Da hast zumindest der Normalbenutzer aber nur die Einstellmöglichkeit
für die Systemschrift (klein/groß), die automatisch die dpi mit ändert
(96 dpi bzw. 120 dpi) und 15 bzw. 12 TwipsPerPixel ergibt. Mir ist noch
kein System untergekommen, bei dem X- und Y-Werte /unterschiedlich/
waren.
Helmut.
Ich hab's noch nicht mit neueren Versionen probiert, aber bei NT4.0 und
Win2000 funktioniert 1).
Da hast zumindest der Normalbenutzer aber nur die Einstellmöglichkeit
für die Systemschrift (klein/groß), die automatisch die dpi mit ändert
(96 dpi bzw. 120 dpi) und 15 bzw. 12 TwipsPerPixel ergibt. Mir ist noch
kein System untergekommen, bei dem X- und Y-Werte /unterschiedlich/
waren.
Helmut.
Wilfried Dietrich
Mar 7, 2012, 5:12:07 AM3/7/12
to
> Die Angabe der Betriebssystemversion wäre hilfreich.
>
> Ich hab's noch nicht mit neueren Versionen probiert, aber bei NT4.0 und
> Win2000 funktioniert 1).
> Da hast zumindest der Normalbenutzer aber nur die Einstellmöglichkeit
> für die Systemschrift (klein/groß), die automatisch die dpi mit ändert
> (96 dpi bzw. 120 dpi) und 15 bzw. 12 TwipsPerPixel ergibt. Mir ist noch
> kein System untergekommen, bei dem X- und Y-Werte /unterschiedlich/
> waren.
... auch auf XP, Vista, W7
>
> Ich hab's noch nicht mit neueren Versionen probiert, aber bei NT4.0 und
> Win2000 funktioniert 1).
> Da hast zumindest der Normalbenutzer aber nur die Einstellmöglichkeit
> für die Systemschrift (klein/groß), die automatisch die dpi mit ändert
> (96 dpi bzw. 120 dpi) und 15 bzw. 12 TwipsPerPixel ergibt. Mir ist noch
> kein System untergekommen, bei dem X- und Y-Werte /unterschiedlich/
> waren.
DPI = 1440 / Screen.TwipsPerPixelX ' bzw. Y
Gruß
Wilfried
Martin KoWi
Mar 7, 2012, 10:39:34 AM3/7/12
to
Am 07.03.2012 11:12, schrieb Wilfried Dietrich:
> ... auch auf XP, Vista, W7
> DPI = 1440 / Screen.TwipsPerPixelX ' bzw. Y
ab Vista ist das nur bedingt richtig!
> ... auch auf XP, Vista, W7
> DPI = 1440 / Screen.TwipsPerPixelX ' bzw. Y
sobald der DWM unter Aero läuft, schlägt bei höheren DPI die sog.
DPI-virtualization zu.
Simpel gesagt "lügt" Windows die Applikation schlichtweg an,
was die DPI betrifft - egal welche Methode man benutzt.
Man kriegt dann immer 96 raus, egal was wirklich eingestellt ist!
Da Hermie geschrieben hat er kriegt den richtigen Wert nicht raus,
nehme ich an, dass genau das bei ihm zutrifft.
http://msdn.microsoft.com/en-us/library/dd464660%28VS.85%29.aspx#dpi_virtualization
Wie schon gesagt ist die Problematik deutlicher komplexer als man denkt.
Es gibts da nämlich noch 2 weitere Einstellungen, die da mitspielen:
1. kann man in den Eigenschaften der EXE einstellen "DPI-Skalierung
deaktivieren"
2. gibt´s in den DPI-Optionen von Windows eine Checkbox "XP-Skalierung"
Auf diese OS-Optionen hat man aber Anwendungsentwickler keinen Einfluss,
so dass die zuverlässigste Methode ist, seine App mittels manifest als
DpiAware zu kennzeichen.
gruß, martin.
R.Kantas
Mar 7, 2012, 11:10:15 AM3/7/12
to
Ein paar Worte zum Zusammenhang zwischen DPI, Twips & Co.:
DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel pro
Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das am
Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
Dir Längeneinheiten für die Programmierung wurden dagegen hardwareunabhängig
als Twips definiert, sodaß die Software mit Koordinaten in Twips rechnen
kann und der jeweilige Ausgabetreiber diese über das Verhältnis
TwipsPerPixelX bzw. ..Y in Pixel umrechnet.
Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
Twips/dot = 1440 Twips/inch.
In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion visualisieren,
wenn man eine Linie Twip für Twip neben der anderen zeichnet und sieht, daß
die Liniendicke nicht kontinuierlich wächst, sondern nach jeweils 15 Linien
um ein Pixel breiter wird.
Die von Windows so genannte "Vergrößerung" des DPI-Wertes - standardmäßig 96
DPI, "Größere Skalierung" 120 DPI - ist irreführend, da ja nicht der
DPI-Wert vergrößert werden kann, sondern lediglich größere Elemente
ausgegeben werden: Gemeint ist, ist daß Windows lediglich um 25% größere
Schriften (und andere Elemente entsprechend vergrößert) ausgibt, so daß
dort, wo bisher z.B. 96 Pixel angesteuert wurden, jetzt eben 120 benötigt
werden.
Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
ändert aber natürlich weder die hardwarebedingten DPI noch den
Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
Soweit ich weiß, ist der aktuell vom System verwendete DPI-Wert noch immer
zu finden unter HKEY_CURRENT_USER\Control
Panel\Desktop\WindowMetrics\AppliedDPI. Dieser Wert durch die
standardmäßigen 96 dividiert gibt den aktuellen Vergrößerungsfaktor. Aber
ein Rechteck mit z.B. 3000 x 2000 Twips wird eben nach wie vor gleich groß
gezeichnet.
Gruß rokas
DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel pro
Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das am
Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
Dir Längeneinheiten für die Programmierung wurden dagegen hardwareunabhängig
als Twips definiert, sodaß die Software mit Koordinaten in Twips rechnen
kann und der jeweilige Ausgabetreiber diese über das Verhältnis
TwipsPerPixelX bzw. ..Y in Pixel umrechnet.
Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
Twips/dot = 1440 Twips/inch.
In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion visualisieren,
wenn man eine Linie Twip für Twip neben der anderen zeichnet und sieht, daß
die Liniendicke nicht kontinuierlich wächst, sondern nach jeweils 15 Linien
um ein Pixel breiter wird.
Die von Windows so genannte "Vergrößerung" des DPI-Wertes - standardmäßig 96
DPI, "Größere Skalierung" 120 DPI - ist irreführend, da ja nicht der
DPI-Wert vergrößert werden kann, sondern lediglich größere Elemente
ausgegeben werden: Gemeint ist, ist daß Windows lediglich um 25% größere
Schriften (und andere Elemente entsprechend vergrößert) ausgibt, so daß
dort, wo bisher z.B. 96 Pixel angesteuert wurden, jetzt eben 120 benötigt
werden.
Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
ändert aber natürlich weder die hardwarebedingten DPI noch den
Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
Soweit ich weiß, ist der aktuell vom System verwendete DPI-Wert noch immer
zu finden unter HKEY_CURRENT_USER\Control
Panel\Desktop\WindowMetrics\AppliedDPI. Dieser Wert durch die
standardmäßigen 96 dividiert gibt den aktuellen Vergrößerungsfaktor. Aber
ein Rechteck mit z.B. 3000 x 2000 Twips wird eben nach wie vor gleich groß
gezeichnet.
Gruß rokas
Uwe Sieber
Mar 7, 2012, 11:15:56 AM3/7/12
to
Martin KoWi wrote:
>
> ...
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx
Private Declare Function SetProcessDPIAware Lib "user32.dll" () As Long
Gruß Uwe
>
> ...
> Auf diese OS-Optionen hat man aber Anwendungsentwickler keinen Einfluss,
> so dass die zuverlässigste Methode ist, seine App mittels manifest als
> DpiAware zu kennzeichen.
SetProcessDPIAware scheint die selbe Wirkung zu haben, oder?
> so dass die zuverlässigste Methode ist, seine App mittels manifest als
> DpiAware zu kennzeichen.
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx
Private Declare Function SetProcessDPIAware Lib "user32.dll" () As Long
Gruß Uwe
Martin KoWi
Mar 7, 2012, 11:37:38 AM3/7/12
to
Am 07.03.2012 17:15, schrieb Uwe Sieber:
> SetProcessDPIAware scheint die selbe Wirkung zu haben, oder?
prinzipiell ja - aber die Betonung liegt auf "scheint" !
> SetProcessDPIAware scheint die selbe Wirkung zu haben, oder?
ich weiss es jetzt nicht auswendig, aber es gab da kranke Effekte,
weil SetProcessDPIAware etwas später zuschlägt als das manifest.
Da waren manche Dinge schon mit falschen DPI initialisiert oder so..
gruß, martin.
Helmut_Meukel
Mar 7, 2012, 2:21:20 PM3/7/12
to
R.Kantas erklärte:
Durch die Auswahl der größeren Schriften *ändern* sich die TwipsPerPixel
von 15 auf nur noch 12! Probier es aus! Es ist ganz einfach:
Screen.Width liefert einen anderen niedrigeren Twips-Wert wenn "Große
Schriften"(=120 dpi) eingestellt ist.
> Soweit ich weiß, ist der aktuell vom System verwendete DPI-Wert noch immer zu
> finden unter HKEY_CURRENT_USER\Control
> Panel\Desktop\WindowMetrics\AppliedDPI. Dieser Wert durch die standardmäßigen
> 96 dividiert gibt den aktuellen Vergrößerungsfaktor. Aber ein Rechteck mit
> z.B. 3000 x 2000 Twips wird eben nach wie vor gleich groß gezeichnet.
Falsch.
Stell den Bildschirm auf 96 dpi ein, ermittle in VB Screen.Width und
zeichne eine Form mit dieser Breite (in Twips) Left und Top beide 0.
Zur Kontrolle das Programm laufen lassen, die Form ist vollständig zu
sehen. jetzt Bildschirm auf 120 dpi umstellen, programm mit identischen
Formmaßen laufen lassen. Was siehst du nicht?
Helmut.
> Ein paar Worte zum Zusammenhang zwischen DPI, Twips & Co.:
>
> DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel pro
> Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das am
> Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
>
> Dir Längeneinheiten für die Programmierung wurden dagegen hardwareunabhängig
> als Twips definiert, sodaß die Software mit Koordinaten in Twips rechnen kann
> und der jeweilige Ausgabetreiber diese über das Verhältnis TwipsPerPixelX
> bzw. ..Y in Pixel umrechnet.
>
> Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
> Twips/dot = 1440 Twips/inch.
>
> In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion visualisieren,
> wenn man eine Linie Twip für Twip neben der anderen zeichnet und sieht, daß
> die Liniendicke nicht kontinuierlich wächst, sondern nach jeweils 15 Linien
> um ein Pixel breiter wird.
>
> Die von Windows so genannte "Vergrößerung" des DPI-Wertes - standardmäßig 96
> DPI, "Größere Skalierung" 120 DPI - ist irreführend, da ja nicht der DPI-Wert
> vergrößert werden kann, sondern lediglich größere Elemente ausgegeben werden:
> Gemeint ist, ist daß Windows lediglich um 25% größere Schriften (und andere
> Elemente entsprechend vergrößert) ausgibt, so daß dort, wo bisher z.B. 96
> Pixel angesteuert wurden, jetzt eben 120 benötigt werden.
>
> Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
> ändert aber natürlich weder die hardwarebedingten DPI noch den
> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
genau das stimmt nicht!
>
> DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel pro
> Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das am
> Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
>
> Dir Längeneinheiten für die Programmierung wurden dagegen hardwareunabhängig
> als Twips definiert, sodaß die Software mit Koordinaten in Twips rechnen kann
> und der jeweilige Ausgabetreiber diese über das Verhältnis TwipsPerPixelX
> bzw. ..Y in Pixel umrechnet.
>
> Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
> Twips/dot = 1440 Twips/inch.
>
> In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion visualisieren,
> wenn man eine Linie Twip für Twip neben der anderen zeichnet und sieht, daß
> die Liniendicke nicht kontinuierlich wächst, sondern nach jeweils 15 Linien
> um ein Pixel breiter wird.
>
> Die von Windows so genannte "Vergrößerung" des DPI-Wertes - standardmäßig 96
> DPI, "Größere Skalierung" 120 DPI - ist irreführend, da ja nicht der DPI-Wert
> vergrößert werden kann, sondern lediglich größere Elemente ausgegeben werden:
> Gemeint ist, ist daß Windows lediglich um 25% größere Schriften (und andere
> Elemente entsprechend vergrößert) ausgibt, so daß dort, wo bisher z.B. 96
> Pixel angesteuert wurden, jetzt eben 120 benötigt werden.
>
> Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
> ändert aber natürlich weder die hardwarebedingten DPI noch den
> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
Durch die Auswahl der größeren Schriften *ändern* sich die TwipsPerPixel
von 15 auf nur noch 12! Probier es aus! Es ist ganz einfach:
Screen.Width liefert einen anderen niedrigeren Twips-Wert wenn "Große
Schriften"(=120 dpi) eingestellt ist.
> Soweit ich weiß, ist der aktuell vom System verwendete DPI-Wert noch immer zu
> finden unter HKEY_CURRENT_USER\Control
> Panel\Desktop\WindowMetrics\AppliedDPI. Dieser Wert durch die standardmäßigen
> 96 dividiert gibt den aktuellen Vergrößerungsfaktor. Aber ein Rechteck mit
> z.B. 3000 x 2000 Twips wird eben nach wie vor gleich groß gezeichnet.
Stell den Bildschirm auf 96 dpi ein, ermittle in VB Screen.Width und
zeichne eine Form mit dieser Breite (in Twips) Left und Top beide 0.
Zur Kontrolle das Programm laufen lassen, die Form ist vollständig zu
sehen. jetzt Bildschirm auf 120 dpi umstellen, programm mit identischen
Formmaßen laufen lassen. Was siehst du nicht?
Helmut.
Schmidt
Mar 7, 2012, 5:37:31 PM3/7/12
to
Am 07.03.2012 09:00, schrieb Hermie:
Die einzig verlässliche Methode, um den *SystemEinstellungs*
DPI-Wert auszulesen, scheint die von R.Kantas schon erwähnte
Registry-Methode zu sein, mit den entspr. Reg.APIs als DWord per:
RegOpenKey
(mit HKEY_CURRENT_USER u. "Control Panel\Desktop\WindowMetrics"
RegQueryValueEx
(mit REG_DWORD u. "AppliedDPI")
Hier mal das Ergebnis meiner Tests auf Win7 im Aero-Mode
(mit aktiviertem "125%" Zoom, ohne generelles "XP-Mode-Häkchen",
um das in meinen Tests dann App-spezifisch über das App-
Kontext-Menü an- und ausschalten zu können):
Fall1: App-Kompilat *ohne* SetProcessDPIAwareAPI oder Manifest:
App-KontextMenü <Skalierung bei hohem DPI-Wert deaktivieren>:
Aus (Default)
Resultate:
App-Window in original definierter Größe (nicht autoresized)
RenderQualität: Blurry
Fontgrößen: wie im Form-Entwurf (bei 96 dpi)
Controlgrößen: wie im Form-Entwurf (nicht resized)
120 (Registry-Methode)
96 (ScreenDC-Methode)
96 (1440 / Screen.TwipsPerPixelX)
App-KontextMenü <Skalierung bei hohem DPI-Wert deaktivieren>:
Ein
Resultate:
App-Window autoresized um den Faktor 1.25
RenderQualität: Klar
Fontgrößen: skaliert auf 120 dpi
Controlgrößen: skaliert um den Faktor 1.25
120 (Registry-Methode)
120 (ScreenDC-Methode)
120 (1440 / Screen.TwipsPerPixelX)
-----------------------------------------------------------------
Fall2: App-Kompilat *mit* SetProcessDPIAware-API im Form_Initialize
App-KontextMenü <Skalierung bei hohem DPI-Wert deaktivieren>:
Aus (Default)
Resultate:
App-Window in original definierter Größe (nicht autoresized)
RenderQualität: Klar
Fontgrößen: wie im Form-Entwurf (bei 96 dpi)
Controlgrößen: wie im Form-Entwurf (nicht resized)
120 (Registry-Methode)
120 (ScreenDC-Methode)
96 (1440 / Screen.TwipsPerPixelX)
App-KontextMenü <Skalierung bei hohem DPI-Wert deaktivieren>:
Ein
Resultate:
App-Window autoresized um den Faktor 1.25
RenderQualität: Klar
Fontgrößen: skaliert auf 120 dpi
Controlgrößen: skaliert um den Faktor 1.25
120 (Registry-Methode)
120 (ScreenDC-Methode)
120 (1440 / Screen.TwipsPerPixelX)
Alles doppelt und dreifach geprüft und die Werte da oben
ebenfalls auf Copy&Paste-Fehler - die sind also verlässlich.
Was als erstes auffällt ist, dass wenn der User per App-
Kontext-Menü das Häkchen setzt bei: "<Skalierung bei hohem
DPI-Wert deaktivieren>", dann sind die Resultate in beiden
Fällen identisch (egal ob der Prozess "DpiAware" geschaltet
war, oder nicht) - was irgendwo auch logisch ist - dann
entspricht das Resultat dem Verhalten auf XP-Systemen.
Fenster und Control-Flächen werden vergrößert, Fonts
ebenso, der RenderOutput ist "scharf".
Und da hier dann generell eine Vergrößerung der hWNDs
herbeigeführt wird, ist mit dem Titel der MS-Checkbox
<Skalierung ... deaktivieren> offenbar die Down-Skalierung
auf 96dpi gemeint - die ist dann also deaktiviert.
Im Standard-Fall jedoch (wenn der User das Häkchen
<Skalierung bei hohem DPI-Wert deaktivieren> nicht setzt)
gibt es interessante Unterschiede beim per API DPI-Aware-
gesetzten Prozess verglichen mit einem normalen VB-Kompilat
(also ganz ohne Manifest - bzw. ohne im Manifest definierte
DPI-Awareness-Einträge).
Die normal kompilierte VB-App ist dann runterskaliert
auf normale ("as designed") Fenster-Größen, alles auf 96dpi -
aber blurry.
Während die API-behandelte, DPI-Aware-App dagegen
ein klares Schriftbild liefert (bei exakt gleichen
Fenster- u. Control-Größen.
Interessant sind auch die verschiedenen Outputs der
dpi-Ermittlungsmethoden in diesem Falle (zur Erinnerung
wir vergleichen AwareApp mit UnAwareApp - bei *nicht*
gesetztem User-Häkchen im entspr. Kontext-Menü):
Hier nochmal (enger zusammenstehend)
Ohne SetProcessDPIAware-API:
120 (Registry-Methode)
96 (ScreenDC-Methode)
96 (1440 / Screen.TwipsPerPixelX)
Mit SetProcessDPIAware-API:
120 (Registry-Methode)
120 (ScreenDC-Methode)
96 (1440 / Screen.TwipsPerPixelX)
Hier mal ein paar interessante "Formeln" die sich daraus
ableiten lassen:
If (ScreenDC-Methode) < (Registry-Methode) Then Win7Blur = True
If (Screen.TwPPX-Meth) < (Registry-Methode) Then Win7DownScale = True
UserCheckBoxChecked = Not Win7DownScale
Ok, hier noch der Code für SetProcessDPIAware
(wenn Sub Main() benutzt wird, dann besser dort platzieren):
Aber wie von Martin bereits erwähnt, greift eine Manifest-
basierte Definition dann noch etwas früher im App-Startup.
Declare Function SetProcessDPIAware Lib "user32" () As Long
Private Sub Form_Initialize()
On Error Resume Next '<- the API is not available on XP and lower
SetProcessDPIAware
On Error GoTo 0
End Sub
Olaf
Ulrich Korndoerfer
Mar 7, 2012, 6:19:49 PM3/7/12
to
Hallo,
Du schreibst zu meinem Lieblingsthema ;-) Leider mißverständlich.
R.Kantas schrieb:
> Dir Längeneinheiten für die Programmierung wurden dagegen
> hardwareunabhängig als Twips definiert, sodaß die Software mit
> Koordinaten in Twips rechnen kann und der jeweilige Ausgabetreiber diese
> über das Verhältnis TwipsPerPixelX bzw. ..Y in Pixel umrechnet.
>
Ja.
> Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
> Twips/dot = 1440 Twips/inch.
>
Das erweckt eine falschen Eindruck. Auch bei einem Monitor mit 200 dpi
sind 1440 Twips ein Inch. Die Monitorauflösung hat damit nichts zu tun
und ändert auch nichts. Die Twips sind nämlich so definiert: 1 TWIP = 1
zwanzigstel eines Pica, wobei ein Pica = 1/72 inch. TWIP ist AFAIR auch
ein Akronym von "Twentieth Pica".
Allerdings handelt es sich dabei um logische inch, also zB 1440 Twip = 1
logischer inch. Physisch werden sie erst bei der Ausgabe auf dem Monitor
durch die Umrechnung zu Pixelzahl mithilfe der angegebenen
Monitorauflösung, die üblicherweise in DPI (dots per inch) angegeben
wird. Wenn die Monitorauflösung allerdings nicht richtig angegeben
wurde, also nicht den Tatsachen entspricht, dann wird logischerweise aus
1440 Twip = 1 logischem inch nicht 1 physicher inch.
> In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion
> visualisieren, wenn man eine Linie Twip für Twip neben der anderen
> zeichnet und sieht, daß die Liniendicke nicht kontinuierlich wächst,
> sondern nach jeweils 15 Linien um ein Pixel breiter wird.
>
> Die von Windows so genannte "Vergrößerung" des DPI-Wertes -
> standardmäßig 96 DPI, "Größere Skalierung" 120 DPI - ist irreführend, da
> ja nicht der DPI-Wert vergrößert werden kann, sondern lediglich größere
> Elemente ausgegeben werden: Gemeint ist, ist daß Windows lediglich um
> 25% größere Schriften (und andere Elemente entsprechend vergrößert)
> ausgibt, so daß dort, wo bisher z.B. 96 Pixel angesteuert wurden, jetzt
> eben 120 benötigt werden.
>
Na ja, irreführend ist nur die Benennung des Vorganges
(Schriftgrößenänderung) durch Microsoft, nicht der Vorgang an sich. Ein
für allemal: mit der Angabe der Auflösung in dpi teilt man Windows die
physische Auflösung des Monitors mit. Bis dato ist das AFAIK leider die
einzige Möglichkeit, dies zu tun, zB kann Windows nicht einfach den
Monitor fragen.
Deshalb braucht man sich nicht wundern, wenn man für einen Monitor mit
zB physischen 96 dpi Windows mitteilt, daß dieser zB 120 dpi hätte, daß
dann einiges schief läuft.
> Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
> ändert aber natürlich weder die hardwarebedingten DPI noch den
> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
> ...
Der Umrechnungsfaktor für die Umrechnung Twips nach Pixel ändert sich
sehr wohl. Allerdings können neuere Betriebssystem (ab Vista) hier
lügen, und unter bestimmten Voraussetzungen einem Programm einfach
andere Werte vorgaukeln.
Also als Faustregel: der DPI-Wert soll mit dem tatsächlichen Monitorwert
übereinstimmen.
Woher kommt dann der üblicherweise damit verbundene Wirrwarr und die
Probleme? Nun, die Probleme beginnen, wenn der User, vielleicht weil er
nicht mehr zwanzig ist und keine Adleraugen hat, möchte, daß ein zum
Betriebssystem gehörendes Programm oder ein anderes Programm das GUI
bzw. GUI-Elemente und die Schrift größer darstellen soll.
Für Windows kann man für diverse "Plätze" (wie Menus,
Schaltflächenbeschriftungen, etc pp), an denen Schrift verwendet wird,
Schriftgrößen vorgeben. Ebenso kann man die Breiten/Höhen diverser
GUI-Elemente global vorgeben (zB Scrolleisten, etc). Alle
Microsoft-Programme und alle anderen Anwendungsprogramme sollten sich
daran halten.
Der Wirrwarr kommt daher, daß sich zum einen eben nicht alle Programme
(inklusive der von Microsoft) an obige Vorgaben halten. Zudem ist leider
auch nicht für alle Arten von GUI-Elementen eine Einstellmöglichkeit
vorhanden.
Deshalb greift der User (notgedrungen) oft zu der Möglichkeit, die
Monitoraufösung falsch anzugeben. Verführt dazu wird er auch durch die
im relevanten Einstellungsdiaolog verwendete irreführende Beschreibung
von Microsoft, die suggeriert, hier könnte man global das System
anweisen, nur die *Schriften* (Stichwort ist hier "Einstellung große
Schriftarten") zu vergrößern.
Bei meinem XP SP3 steht nun immerhin im Dialog "Eigenschaften von xyz
Monitor", Reiter "Allgemein", Feld "Anzeige":
"Der DPI-Wert kann als Kompensierung vergrößert werden, wenn Elemente
bei der aktuellen Bildschirmauflösung zu klein angezeigt werden. Klicken
Sie auf "Abbrechen" und wechseln Sie zur Registerkarte "Darstellung", um
nur den Schriftgrad zu ändern."
Und drunter ist dann eine Ausklappliste mit der Beschriftung
"DPI-Einstellung". Also der Text ist schon um Längen besser als das, was
hier unter W2K und früher stand, läßt aber an Deutlichkeit immer noch
einiges vermissen.
Vollends klar werden, was man hier einstellt, sollte es einem werden,
wenn man "benutzerdefinierte Einstellung" wählt. Dann bekommt man
nämlich ein Bildschirmlineal präsentiert, mithilfe dessen man die realen
DPI *messen* kann!
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
Du schreibst zu meinem Lieblingsthema ;-) Leider mißverständlich.
R.Kantas schrieb:
> Ein paar Worte zum Zusammenhang zwischen DPI, Twips & Co.:
>
> DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel
> pro Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das
> am Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
>
Ok.
>
> DPI ist eine unveränderliche Hardwaregröße und gibt an, wieviele Pixel
> pro Längeneinheit die Ausgabe-Device realisieren kann. Früher waren das
> am Bildschirm üblicherweise 96 dots/inch. Ein Inch sind ca. 2,54 cm.
>
> Dir Längeneinheiten für die Programmierung wurden dagegen
> hardwareunabhängig als Twips definiert, sodaß die Software mit
> Koordinaten in Twips rechnen kann und der jeweilige Ausgabetreiber diese
> über das Verhältnis TwipsPerPixelX bzw. ..Y in Pixel umrechnet.
>
> Kann die Ausgabedevice also z.B. 96 DPI, dann sind 96 dots/inch * 15
> Twips/dot = 1440 Twips/inch.
>
sind 1440 Twips ein Inch. Die Monitorauflösung hat damit nichts zu tun
und ändert auch nichts. Die Twips sind nämlich so definiert: 1 TWIP = 1
zwanzigstel eines Pica, wobei ein Pica = 1/72 inch. TWIP ist AFAIR auch
ein Akronym von "Twentieth Pica".
Allerdings handelt es sich dabei um logische inch, also zB 1440 Twip = 1
logischer inch. Physisch werden sie erst bei der Ausgabe auf dem Monitor
durch die Umrechnung zu Pixelzahl mithilfe der angegebenen
Monitorauflösung, die üblicherweise in DPI (dots per inch) angegeben
wird. Wenn die Monitorauflösung allerdings nicht richtig angegeben
wurde, also nicht den Tatsachen entspricht, dann wird logischerweise aus
1440 Twip = 1 logischem inch nicht 1 physicher inch.
> In VB läßt sich der Zusammenhang z.B. mit der LINE-Funktion
> visualisieren, wenn man eine Linie Twip für Twip neben der anderen
> zeichnet und sieht, daß die Liniendicke nicht kontinuierlich wächst,
> sondern nach jeweils 15 Linien um ein Pixel breiter wird.
>
> Die von Windows so genannte "Vergrößerung" des DPI-Wertes -
> standardmäßig 96 DPI, "Größere Skalierung" 120 DPI - ist irreführend, da
> ja nicht der DPI-Wert vergrößert werden kann, sondern lediglich größere
> Elemente ausgegeben werden: Gemeint ist, ist daß Windows lediglich um
> 25% größere Schriften (und andere Elemente entsprechend vergrößert)
> ausgibt, so daß dort, wo bisher z.B. 96 Pixel angesteuert wurden, jetzt
> eben 120 benötigt werden.
>
(Schriftgrößenänderung) durch Microsoft, nicht der Vorgang an sich. Ein
für allemal: mit der Angabe der Auflösung in dpi teilt man Windows die
physische Auflösung des Monitors mit. Bis dato ist das AFAIK leider die
einzige Möglichkeit, dies zu tun, zB kann Windows nicht einfach den
Monitor fragen.
Deshalb braucht man sich nicht wundern, wenn man für einen Monitor mit
zB physischen 96 dpi Windows mitteilt, daß dieser zB 120 dpi hätte, daß
dann einiges schief läuft.
> Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
> ändert aber natürlich weder die hardwarebedingten DPI noch den
> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
Der Umrechnungsfaktor für die Umrechnung Twips nach Pixel ändert sich
sehr wohl. Allerdings können neuere Betriebssystem (ab Vista) hier
lügen, und unter bestimmten Voraussetzungen einem Programm einfach
andere Werte vorgaukeln.
Also als Faustregel: der DPI-Wert soll mit dem tatsächlichen Monitorwert
übereinstimmen.
Woher kommt dann der üblicherweise damit verbundene Wirrwarr und die
Probleme? Nun, die Probleme beginnen, wenn der User, vielleicht weil er
nicht mehr zwanzig ist und keine Adleraugen hat, möchte, daß ein zum
Betriebssystem gehörendes Programm oder ein anderes Programm das GUI
bzw. GUI-Elemente und die Schrift größer darstellen soll.
Für Windows kann man für diverse "Plätze" (wie Menus,
Schaltflächenbeschriftungen, etc pp), an denen Schrift verwendet wird,
Schriftgrößen vorgeben. Ebenso kann man die Breiten/Höhen diverser
GUI-Elemente global vorgeben (zB Scrolleisten, etc). Alle
Microsoft-Programme und alle anderen Anwendungsprogramme sollten sich
daran halten.
Der Wirrwarr kommt daher, daß sich zum einen eben nicht alle Programme
(inklusive der von Microsoft) an obige Vorgaben halten. Zudem ist leider
auch nicht für alle Arten von GUI-Elementen eine Einstellmöglichkeit
vorhanden.
Deshalb greift der User (notgedrungen) oft zu der Möglichkeit, die
Monitoraufösung falsch anzugeben. Verführt dazu wird er auch durch die
im relevanten Einstellungsdiaolog verwendete irreführende Beschreibung
von Microsoft, die suggeriert, hier könnte man global das System
anweisen, nur die *Schriften* (Stichwort ist hier "Einstellung große
Schriftarten") zu vergrößern.
Bei meinem XP SP3 steht nun immerhin im Dialog "Eigenschaften von xyz
Monitor", Reiter "Allgemein", Feld "Anzeige":
"Der DPI-Wert kann als Kompensierung vergrößert werden, wenn Elemente
bei der aktuellen Bildschirmauflösung zu klein angezeigt werden. Klicken
Sie auf "Abbrechen" und wechseln Sie zur Registerkarte "Darstellung", um
nur den Schriftgrad zu ändern."
Und drunter ist dann eine Ausklappliste mit der Beschriftung
"DPI-Einstellung". Also der Text ist schon um Längen besser als das, was
hier unter W2K und früher stand, läßt aber an Deutlichkeit immer noch
einiges vermissen.
Vollends klar werden, was man hier einstellt, sollte es einem werden,
wenn man "benutzerdefinierte Einstellung" wählt. Dann bekommt man
nämlich ein Bildschirmlineal präsentiert, mithilfe dessen man die realen
DPI *messen* kann!
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
Hermie
Mar 8, 2012, 12:36:06 AM3/8/12
to
Saukomplex das Thema.
vielen Dank für die vielen Antworten!
Liebe Grüße,
Hermann
vielen Dank für die vielen Antworten!
Liebe Grüße,
Hermann
R.Kantas
Mar 8, 2012, 4:01:17 AM3/8/12
to
>> Dieses Verhalten von Windows, einfach nur größere Schriften anzuwenden,
>> ändert aber natürlich weder die hardwarebedingten DPI noch den
>> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
>> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
>
> genau das stimmt nicht!
> Durch die Auswahl der größeren Schriften *ändern* sich die TwipsPerPixel
> von 15 auf nur noch 12! Probier es aus! Es ist ganz einfach:
> Screen.Width liefert einen anderen niedrigeren Twips-Wert wenn "Große
> Schriften"(=120 dpi) eingestellt ist.
Microsoft kann in Windows zwar viel drehen, aber die Abstände der Pixel in
>> ändert aber natürlich weder die hardwarebedingten DPI noch den
>> Umrechnungsmaßstab Twips pro Pixel, weshalb auch nach der Einstellung
>> größerer 'DPI'-Werte beide noch genau so groß sind wie vorher.
>
> genau das stimmt nicht!
> Durch die Auswahl der größeren Schriften *ändern* sich die TwipsPerPixel
> von 15 auf nur noch 12! Probier es aus! Es ist ganz einfach:
> Screen.Width liefert einen anderen niedrigeren Twips-Wert wenn "Große
> Schriften"(=120 dpi) eingestellt ist.
der Lochmaske respektive die der Leuchtpunkte der TFT können auch sie nicht
manipulieren :-)
Was sie können, ist der Applikation vorzugaukeln, sie laufe auf einem
96DPI-Schirm und dann die Werte intern nochmals umrechnen.
Was sie letztendlich tun, hängt u.a. von der OS-Version und vom
Bildschirmtreiber ab. Das von Dir beschrieben Verhalten (niedrigerer
Twips-Wert) hätte ich zwar erst auch erwartet (denn dafür sind TwipsPerPixel
und DPI da), konnte ich aber in meinem on-the-fly-Test gestern auf XP gerade
*nicht* beobachten.
Was das Vorgaukeln betrifft, so ist übrigens das gestern von Martin KoWi
verlinkte Dokument
http://msdn.microsoft.com/en-us/library/dd464660%28VS.85%29.aspx#dpi_virtualization
sehr aufschlußreich. Ein typischer Fall, wie in Windows unsaubere Lösungen
(nur teilweise Skalierung graphischer Elemente) ausgebügelt werden sollen
und dann nur noch mehr Konfusion verursachen, anstatt gleich eine zwar
komplexere, dafür aber stringente Lösung zu schaffen. Weswegen ich um solche
Dinge immer einen möglichst großen Bogen mache....:-)
Karl Honig
Mar 16, 2012, 8:51:04 AM3/16/12
to
Am 08.03.2012, 06:36 Uhr, schrieb Hermie <herman...@lycos.de>:
Hallo zusammen,
> Saukomplex das Thema.
Ja, und ich bekomme jetzt auch ein Problemchen.
'Mein' Dialogfenster funktioniert super, wenn unter Win7 125% eingestellt
ist.
Genau wie erwartet.
Fast.
Oben im Dialog ist ein Bild (500 x 300 pixel).
Danach richte ich die Dialogbreite aus. (frm_Dialog.width = pic_bla.width).
Die ganze schoene Skaliererei die Windows macht scheint auf die picturebox
nicht zu wirken.
Das Imagecontrol macht es auch nicht mit.
Frage:
Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt machen...
Bin fuer jeden Tip dankbar.
Viele Gruesse,
Karl
Hallo zusammen,
> Saukomplex das Thema.
Ja, und ich bekomme jetzt auch ein Problemchen.
'Mein' Dialogfenster funktioniert super, wenn unter Win7 125% eingestellt
ist.
Genau wie erwartet.
Fast.
Oben im Dialog ist ein Bild (500 x 300 pixel).
Danach richte ich die Dialogbreite aus. (frm_Dialog.width = pic_bla.width).
Die ganze schoene Skaliererei die Windows macht scheint auf die picturebox
nicht zu wirken.
Das Imagecontrol macht es auch nicht mit.
Frage:
Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt machen...
Bin fuer jeden Tip dankbar.
Viele Gruesse,
Karl
R.Kantas
Mar 16, 2012, 9:09:51 AM3/16/12
to
> Frage:
> Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
> Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt machen...
>
> Bin fuer jeden Tip dankbar.
Vergrößerungsfaktor ermitteln und Bild z.B. mit PaintPicture selbst
> Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
> Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt machen...
>
> Bin fuer jeden Tip dankbar.
vergrößern.
Gruß rokas
Karl Honig
Mar 16, 2012, 10:22:11 AM3/16/12
to
Am 16.03.2012, 14:09 Uhr, schrieb R.Kantas <r...@online.de>:
Hallo rokas,
>> Frage:
>> Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
>> Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt
>> machen...
Haette ich auch selbst drauf kommen koennen, naja.
Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut aussehen
tut das nicht.
Gibt es vielleicht noch eine andere Moeglichkeit, die ein bischen
Antialiasing macht?
Oder irgendein Control, das die Groessenanderung der DPI-Skalierung
automatisch mitmacht?
Karl
Hallo rokas,
>> Frage:
>> Wie bekomme ich das Bild in die richtige, 125% enstprechende Groesse?
>> Ein zweites und ein drittes Bild (150%) will ich nicht unbedingt
>> machen...
> Vergrößerungsfaktor ermitteln und Bild z.B. mit PaintPicture selbst
> vergrößern.
Oh ja, das ist ja naheliegend!
> vergrößern.
Haette ich auch selbst drauf kommen koennen, naja.
Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut aussehen
tut das nicht.
Gibt es vielleicht noch eine andere Moeglichkeit, die ein bischen
Antialiasing macht?
Oder irgendein Control, das die Groessenanderung der DPI-Skalierung
automatisch mitmacht?
Karl
Karl Honig
Mar 16, 2012, 12:06:16 PM3/16/12
to
Am 16.03.2012, 15:22 Uhr, schrieb Karl Honig
<spanke...@googlemail.com>:
> Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut
> aussehen tut das nicht.
Hab selbst was akzeptables gefunden:
Load and Resize Pictures with GDI+
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=48352&lngWId=1
Funktioniert perfekt!
Schoenes Wochenende!
Karl
<spanke...@googlemail.com>:
> Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut
> aussehen tut das nicht.
Load and Resize Pictures with GDI+
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=48352&lngWId=1
Funktioniert perfekt!
Schoenes Wochenende!
Karl
Schmidt
Mar 16, 2012, 12:29:40 PM3/16/12
to
Am 16.03.2012 15:22, schrieb Karl Honig:
> Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut
> aussehen tut das nicht.
> Gibt es vielleicht noch eine andere Moeglichkeit, die ein bischen
> Antialiasing macht?
Vor dem Stretchen mittels StretchBlt den DC per SetStretchBltMode
> Gesagt, getan, aber egal ob mit PaintPicture oder StretchBlt, gut
> aussehen tut das nicht.
> Gibt es vielleicht noch eine andere Moeglichkeit, die ein bischen
> Antialiasing macht?
auf HalfTone = 4 setzen.
Olaf
0 new messages