welche DPI Auflösung benutzt ihr ?

[AUGE_OHR]

welche Auflösung benutzt ihr als "Vorgabe" ?

hier paar Beispiele

Code: Alles auswählen

Description	Horizontal Vertical  Width  Panel DPI  OS DPI Scale level
17"   WXGA+  	1440		900 		17  		100		96 	100%
15.4" WXGA+  	1440		900 		15.4		110		96 	100%
15.4" WXGA		1280		768 		15.4		97 		96 	100%
14.1" WXGA		1280		768 		14.1		106		96 	100%
13.3" WXGA		1280		768 		13.3		112		96 	100%
17"   WUXGA  	1920		1200		17  		133		120	125%
17"   WSXGA+ 	1680		1050		17  		117		120	125%
15.4" WSXGA+ 	1680		1050		15.4		129		120	125%
14.1" WXGA+  	1440		900 		14.1		120		120	125%
13.3" WXGA+  	1440		900 		13.3		127		120	125%
12.1" WXGA+  	1280		768 		12.1		123		120	125%
15.4" WUXGA  	1920		1200		15.4		147		144	150%

[Jan]

Jimmy,

als Vorgabe für was? Für meinen Monitor? Für meine Programme?

Für meine Programme immer die Bildschirmgröße des Users. Bislang waren das immer Programme, die gerne so viel Platz wie möglich in Anspruch nehmen. Also schreibe ich die Anordung und Größe der XBParts so, das sie (fast) immer passen. Nicht bei Standard-VGA, das ist heutzutage doch arg winzig. Aber sonst ...

Jan

[brandelh]

Hi,

ich bemühe mich redlich mit 1024x768 Bildpunkten auszukommen. Ob der Anwender dann 96 oder 120 dpi eingestellt hat ist sein Bier

[AUGE_OHR]

hi

worauf ich raus will ? "DPI-Aware" siehe http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[Martin Altmann]

Jimmy,
wo ist das Problem? Du brauchst doch nur die aktuelle DPI-Anzahl ermitteln, zum Standard von 96 ins Verhältnis setzen und Deine Postions-/Größenkoordinaten mit diesem Faktor multiplizieren. Schon passt es.

Code: Alles auswählen

FUNCTION AppDesktopDPI()
LOCAL nHWnd := AppDesktop():GetHWnd()
LOCAL nHDC := DllCall("User32.DLL", DLL_STDCALL, "GetDC", nHWnd)
LOCAL nLogPix := 96 // default for Small Fonts
if nHDC > 0
	nLogPix := DllCall("GDI32.DLL", DLL_STDCALL, "GetDeviceCaps", nHDC, LOGPIXELSY )
	DllCall("User32.DLL", DLL_STDCALL, "ReleaseDC", nHWnd, nHDC)
endif
return (nLogPix)

....

   nZoomV := ( AppDesktopDPI() / 96 )
   oDlg := XbpDialog():new( AppDesktop(), SetAppWindow(), aPos, { int( nZoomV * 250 ), int( nZoomV * 280 ) }, , .F.)
   oDlg:taskList := .F.
   oDlg:minButton:= .F.
   oDlg:maxButton:= .F.
   oDlg:border   := XBPDLG_RAISEDBORDERTHICK_FIXED
   oDlg:title    := cTitle
   oDlg:create()
   oDlg:Close    := { || lExit := .T. }

...

Viele Grüße,
Martin

[AUGE_OHR]

wo ist das Problem?

kein Problem sondern eine Umfrage

Du brauchst doch nur die aktuelle DPI-Anzahl ermitteln, zum Standard von 96 ins Verhältnis setzen und Deine Postions-/Größenkoordinaten mit diesem Faktor multiplizieren. Schon passt es.

das ist doch schon mal ein "Anfang" wie es mit der Grösse der XbParts gemacht wird, aber was ist mit den Fonts ?
der Title des Artikel ist : "Writing High-DPI Win32 Applications" und da spielt der Font eine entscheidende Rolle.

das ganze könnte man weiter ausführen ... aber hier geht es mir nur um die Umfrage, danke.

[Jan]

Jimmy,

wie so oft verstehe ich überhaupt nicht, worauf Du eigentlich mit Deiner Frage und der (nachgereichten?) Umfrage hinaus willst. Ich kann das Problem einfach nicht erkennen, um das man sich einen Kopf machen sollte/müsste.

Jan

[Martin Altmann]

Jimmy,

das ist doch schon mal ein "Anfang" wie es mit der Grösse der XbParts gemacht wird, aber was ist mit den Fonts ?

'tschuldigung - aber das ist doch Unsinn! Den Font skaliert doch Dein OS in der Größe, die der Nutzer eingestellt hat! Das willst Du ja wohl nicht umdefinieren, sonst würdest Du ja gegen den Willen des Nutzers agieren!
Das Problem ist nur, dass bei einer höheren DPI-Auflösung Deine Controls u.U. ineinander laufen bzw. der Platz für die Anzeige des Textes (z.B. bei einem Static) zu gering ist (oder - bei einer noch kleineren DPI-Anzahl - unnötig groß)!

... aber hier geht es mir nur um die Umfrage, danke.

was ich bereits beantwortet hatte (letzte Option)

Viele Grüße,
Martin

[Jan]

Jimmy,

wenn ich Deiner Tabelle oben Glauben schenken darf, dan hat mein Entwicklungsrechner 120 DPI. Die allermeisten meiner Kunden arbeiten aber mit 96 DPI. Bislang hat noch niemand sich wegen irgendwie deplazierten Controlls oder falsch dimensionierter Fonts gemeldet. Und mir ist das auf anderen Rechnern auch noch nie aufgefallen. Das gilt sowohl für selbstskalierende als auch mit fester Fenstergröße programmierte Anwendungen.

Daher kann ich Deine Frage auch nicht wirklich nachvollziehen.

Jan

[Manfred]

Jan,

wenn Du das so machst, dann sollte es auch keine Probleme geben. Andersherum wird ein Schuh draus. Wenn Du mit 96dpi entwickelst, dann steht die Chance groß, dass der Anwender, der mit 120 dpi anschaut nicht mehr richtig Platz hat. Weder in den Eingabefeldern, noch auf dem Bildschirm.

[Jan]

Manfred,

aber alle meine auf dem anderen System mit 96 DPI entwicklenten Programme laufen auch auf meinem Schlepptop optisch einwandfrei...

Jan

[Manfred]

Naja,

ich kann da nur aus eigener Erfahrung sprechen. 96dpi auf 120dpi macht etwas Platzprobleme in Eingabefeldern z.B. Das paßt nicht alle sichtbar rein.

Aber ich kann das gerne nochmal testen. Meine mich aber bei Kunden an sowas erinnern zu können. hat auch ne Zeit gedauert, bis ich das geschnallt habe, woran das damals lag.

[Martin Altmann]

Manfred,
brauchst Du nicht testen - dem ist so! Wenn man nicht genügend Luft einkalkuliert, sondern auf Kante aneinanderreiht, passt es dann nicht.

Viele Grüße,
Martin

[UliTs]

Die DPI-Auflösung ist (eigentlich) völlig egal, da es Windows auch nicht interessiert .
Wichtig ist der Scale Level, da dadurch für die Schriftgrößen UNABHÄNGIG von der DPI-Auflösung unterschiedliche viele Pixel benutzt werden.
Und wenn man mit absoluten Positionen und Größen auf Pixel-Ebene arbeitet (was die meisten und auch ich machen), muss dies zwangsläufig bei beliebigem Scale Level schiefgehen . Das Problem hat man ja auch, wenn der Anwender das Dialogfenster in der Größe verändert.

Uli

[Manfred]

OK,

dann hake ich hier nochmals nach. Wie ist es denn, wenn man "nur" den ersten Part feste setzt und von da an nur noch "relativ" zu den Vorgängern positioniert?

Wobei ich hauptsächlich das Problem in den Eingabefeldern sehe.

[Martin Altmann]

Manfred,
solange Du auch die Größe fest setzt, wirst Du scheitern

Viele Grüße,
Martin

[Manfred]

Was heißt jetzt: die Größe?

Eingabebereich? Part?

[Martin Altmann]

Alles!
Parts und drawingarea (wir sind hier ja nicht beim eXpress++-Bereich!)

Viele Grüße,
Martin

[Manfred]

Aha,

dann wäre mal interessant, wie man sowas vernünftig dynamisch anpassen kann. Da stehe ich nämlich noch auf etwas unsicheren Füßen.

[Martin Altmann]

Brauchst Du doch nicht! Hast Du den link bei MS nicht gelesen? Es geht nicht dynamisch!
Bei 7 muss man sich ab- und neu anmelden, bei älteren sogar neu starten.

Viele Grüße,
Martin

[Manfred]

Nee, habe ich nicht gelesen. Ich denke aber auch, dass ich was anderes meine. Mit dynamisch meinte ich, dass es immer paßt. Also die Anwendung sozusagen weiß, was angesagt ist.

[AUGE_OHR]

hi,

es freut mich das ihr hier so rege über das Thema diskutiert, aber ich habe den "Verdacht" das ihr den Artikel nicht gelesen habt ?

der Artikel ist für Vista / Win7 und da wird das DPI "Scaleing" vom DWM "kontrolliert" und das bringt bei der Methode von Martin diesen Effekt

Unscharf.JPG (16.77 KiB) 6387 mal betrachtet

das ganze ist "Blurred" ... das ist DWM

Es reicht also nicht aus mit X,Y Faktor die Grösse zu korrigieren, man muss auch ... aber das wäre ein Thema für einen Vortrag.

p.s. wer noch nicht abgestimmt hat möge es bitte (!!!) tun, danke