border berechnen eines edit control

Meep Meep

hallo leute

wie kann ich die border-dicke des edit controls berechnen/abfragen ?

ich erstelle ein edit control mit WS_VISIBLE|WS_TABSTOP|WS_CHILD|WS_BORDER.
danach bekommt das control einen neuen font zugewiesen.
wenn ich die hoehe des edits auf tmHeight des fonts setze dann ist das zu klein fuer WS_BORDER. wenn ich ins edit feld klicke
verschwinden oben und unten die border. wenn ich oben und unten 2 pixel dazu nehme dann passt das.
hab es mit AdjustWindowRectEx propiert, aber da bleibt RECT gleich.

AdjustWindowRectEx(&rc, GetWindowLongPtr(h, GWL_STYLE), FALSE, GetWindowLongPtr(h, GWL_EXSTYLE));

wie mach ich das richtig ?

dachte mir ich les einfach mal WindowRect und ClientRect aus und berechne halt die differenz und korrigiere mit dem wert die hoehe.
aber GetClientRect und GetWindowRect liefern auch die selbe groesse.
gehoert der gezeichnete border zum clientbereich ?

Meep Meep

DocShoe

Du kannst mal schauen, ob es für GetSystemMetrics eine Konstante gibt, die dir die Rahmendicke eines Fensters zurückgibt (vllt. SM_CXBORDER o.Ä.). Möglicherweise hängt die zu benutzende Konstante für den GetSystemMetrics auch noch von den verwendeten Fensterstilen ab.

bei mir liefert folgender Code folgendes:

GetTextMetrics(GetDC(GetDlgItem(hWnd, DLG_EDIT1)), &tm);
HELP(va("tm.tmHeight: %i\r\n\r\n", tm.tmHeight));							//=16
GetWindowRect(GetDlgItem(hWnd, DLG_EDIT1), &rc);
HELP(va("GetWindowRect: %i\r\n\r\n", (rc.bottom - rc.top))); 				//=20
GetClientRect(GetDlgItem(hWnd, DLG_EDIT1), &rc);
HELP(va("GetClientRect: %i\r\n\r\n", (rc.bottom - rc.top)));				//=16

Die Strichstärke des Rahmens ist 1 Pixel (mit Paintshop nachgemessen) d.h. der Clientbereich ist im inneren des Editfelds oben wie unten je nochmals einen Pixel kleiner. Sieht für mich plausibel aus.

Ich denke du solltest tm.height (alter font) bestimmen, dann tm.height (neuer font) und das Editfeld um die Differenz vergrößern.

Martin Richter

Bei WS_BORDER baut das Edit Control einen eigenen Rahmen. (Siehe EM_GETRECT)
Wenn man mit DLUs rechnet ist es ganz einfach

Die Höhe ist immer 12 DLUs in anderen Woeten, der Rahmen ist immer die normale Font-Höhe mal 1,5. Das heißt der Rahmen oben und unten ist 1/4 Font Höhe.

Der Rahmen rechts und links sind zusammen 4 DLUs (oder evtl. 8 ich weiß es nicht mehr ganau). Also eine durchschnitliche Zeichenbreite, davon also 2 rechts 2 Links.

Meep Meep

Martin Richter schrieb:

Bei WS_BORDER baut das Edit Control einen eigenen Rahmen. (Siehe EM_GETRECT)
Wenn man mit DLUs rechnet ist es ganz einfach

Die Höhe ist immer 12 DLUs in anderen Woeten, der Rahmen ist immer die normale Font-Höhe mal 1,5. Das heißt der Rahmen oben und unten ist 1/4 Font Höhe.

Der Rahmen rechts und links sind zusammen 4 DLUs (oder evtl. 8 ich weiß es nicht mehr ganau). Also eine durchschnitliche Zeichenbreite, davon also 2 rechts 2 Links.

mal ne dumme frage:
angenommen die durchschnittliche zeichenbreite ist 7 pixel und angenommen der rechte und linke ergeben zusammen 4DLUs.
1 DLU = 7/4 = 1
ist das der rechte und linke rand jeweils 2 pixel ?
oder: 7 pixel /2 = 2 DLUs = 3 pixel
dann waere jeweils rechts und links ein rand von 3 pixel
oder werden die kompletten 7 pixel auf links und rechts aufgeteilt: z.b. 3 rechts und 4 pixel links

oder sollte man bis zum ende immer mit floats rechnen und dann am ende erst runden ? wobei das obere beispiel mit 3.5 pixel eh nicht geht. also verschwindet ein pixel. richtig ?

Meep Meep

Martin Richter

Darum kümmere ich mich gar nicht.

Ich dividiere und erhalte linken und rechten rand. D.h. i.a. den kleineren Wert wenn es ungerade ist. Die Höhe/Breite ist fix und damit ist der untere und rechte Rand auch gegeben.

So macht es auch IMHO das Edit Control. Allerdings habe ich das zuletzt geprüft als es noch Windows 3.1 gab.