| |

Fortgeschrittene ProgrammierungRe: vb6 Controlgröße stimmt nicht bei benutzerdifinierter DPI-Einstellung | |  | Autor: Preisser | Datum: 26.11.09 17:56 |
| Hallo,
ich habs grade bei mir mal ausprobiert; ich vermute mal, das hängt mit der Umrechnung zwischen Twips und Pixel zusammen.
Man kann ja in VB6 zwischen den Maßeinheiten Pixel und Twips (und evtl. noch andere) wählen, wobei Pixel exakt eben die Pixel sind, wohingegen sich die Twips an der DPI-Einstellung ausrichten.
VB bietet ja da zur Umrechnung beispielsweise Screen.TwipsPerPixelX und Screen.TwipsPerPixelY. Diese geben also an, wie vielen Twips ein Pixel entspricht. Wenn der Benutzer die DPI-Einstellung erhöht (also größere Schriften), müssen alle Controls größer angezeigt werden, damit die Schrift noch hineinpasst. Da ja an den Width- und Height-Einstellungen nichts geändert wird und diese in Twips angegeben sind, werden dann die Screen.TwipsPerPixel-Werte kleiner, da sich ja die Breite in Pixel aus (Breite in Twips) / Screen.TwipsPerPixel ergibt.
Standardmäßig (bei 100%) haben Screen.TwipsPerPixelX und Y den Wert 15, bei 125% den Wert 12 und bei 150% den Wert 10.
Der Wert dieser Variablen errechnet sich also z. B. aus 15 /(DPI-Faktor), also bei 125% sind dies 15 / 1,25 = 12.
Bei anderen Werten wie 130% müssten es dementsprechend 15 / 1,3 = 11,5385... sein; jedoch gibt VB nur 11 an, also hat die Variable immer einen Ganzzahlwert. Dieser weggefallene Nachkommaanteil 0,5385... verursacht anscheinend das Problem. Wenn man einen Wert nimmt, wo der Rest kleiner ist, z. B. 136%: 15 / 1,36 = 11,0294, wo also nur ein wesentlich kleinerer Unterschied von 0,0294 zwischen der Gleitkomma- und Ganzzahl ist, hat das Tabstrip-Control fast die komplette Breite der Form, wohingegen bei einer Differenz von 0,5... ein größerer Abstand zwischen Breite des TabStrip und der Form ist.
Diese Differenz aus der Breite der TabStrip und der Form ist direkt proportional zu der Breite der Form: Je breiter man die Form zieht, desto größer wird der Abstand zwischen dem rechten Rand des TabStrip und der Form, was allem Anschein nach an dieser Umrechnung zwischen Twips und Pixel liegt.
Da das TabStrip-Control tatsächlich kleiner ist als es eigentlich sein müsste, bedeutet dies, der Screen.TwipsPerPixelX Wert bei der Tabstrip-Breite ist größer als der, der bei der Umrechnung der Formbreite von Pixel in Twips benutzt wurde.
Es könnte also sein, dass das TabStrip als externes Steuerelement (stammt aus einer OCX-Datei) zur Umrechnung den Faktor als Gleitkommazahl benutzt, alle VB-internen Steuerelemente wie Label und die Form selbst dagegen nur den Ganzzahlanteil. Dafür spricht eben auch, dass VB als Wert den Ganzzahlanteil 11 statt 11,53... angibt und der Label, der ja ein VB-internes Steuerelement ist, die komplette Breite der Form einnimmt.
Beispiel: Der DPI-Wert ist 130% des Originalwertes und eine Form hat eine Breite von 100 Pixel.
Breite der Form in Twips bei Ganzzahlfaktor-Umrechnung: 100 * Int(15 / 1,3) = 100 * 11 = 1100 Twips.
Rück-Umrechnung: Breite des TabStrip-Controls in Pixel mit exakter Gleitkommawert-Umrechnung: 1100 / (15 / 1,3) = 95,333... = 95 Pixel.
Sei B die Breite der Form und D die DPI-Einstellung (z. B. 130%, also D = 1.3). Dann ist die Differenz in Pixel zwischen der Breite der Form und der Breite des Tabstrip-Controls = B * (1 - Int(15 / D) / (15 / D)).
Dieser Graph stellt die Differenz der Breiten einer Form und eines Tabstrip-Controls bei einer Form mit einer Breite von 100 Pixeln in Abhängigkeit des DPI-Faktors dar (120 auf der x-Achse sind 120%).
Um das Problem zu lösen, könnte man evtl. mit APIs die DPI-Einstellung auslesen, und über diese dann die Breite des TabStrips umrechnen.
Wenn also der DPI-Faktor (z. B. "1.3" bei 130%) in der Variable DPI stünde, wäre die Breite des TabStrips:
TabStrip2.Width = Me.ScaleWidth / Int(15 / DPI) * (15 / DPI)
Beitrag wurde zuletzt am 26.11.09 um 19:25:10 editiert. |  |
 | Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
  |
|
sevWizard für VB5/6 
Professionelle Assistenten im Handumdrehen
Erstellen Sie eigene Assistenten (Wizards) im Look & Feel von Windows 2000/XP - mit allem Komfort und zwar in Windeseile :-) Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|