Even Alignment of client area

[Tight_Coder_Ex]

For reasons that are not really relevant to the question I hand bomb all my dialog boxes, meaning I don't use resources or API's designed to handle dialog boxes.

What I need to do is have coordinates aligned to modulus 16.  My window is 800 x 600 -- 320H x 258H.
Window has fixed size, thin frame with static and client edges. What I've used is

Code Select Expand



push EX_STYLE
push TRUE
push STYLE
push edi
call AdjustWindowRectEx


Unfortunately what I wind up with is 31E x 250, why I'm losing 8 pixels vertically is another query.
To get my center line of the left half of the screen (Width/4) I right shift twice, but instead of getting 200 I get 199. Anyway you probably get the point by now so my solution is to use  MoveWindow or SetWindowPos until parent window has an evenly aligned client area.  In this case X position would have to be increased by two pixels and the vertical by 8

Ideas please

[dedndave]

well - i would start off with CS_BYTEALIGNCLIENT in the WNDCLASSEX structure
then, rather than messing with the position of the window, i would simply calculate what the right edge needed to be and size it
an API function that you may find useful is AdjustWindowRect
after that, you could keep it lined up in the WM_SIZE handler
if they are making it larger, round up
if they are making it smaller, round down   :P

[Tight_Coder_Ex]

I've used both AdjustWindowRectEx & CS_BYTEALIGNCLIENT.

WM_SIZE is called after WM_CREATE, so I'm going to try moving my code to there, otherwise I've already set sizes of 820 x 648 and that gives me close to the size of client area I want 810 x 612, but at least with both values bits 0 & 1 are null.

As it turns out my three horizontal controls are not evenly aligned horizontally, so these odd numbered values weren't causing the problem to begin with.

[hutch--]

TC,

There are variables that are system dependent, things like the border width is usually a user setting and to get a safe client area size you need to calculate those sizes before you set the window size with MoveWindow() or SetWindowPos(). I think you can get most of the data you need with a call to GetSystemMetrics().

[Tight_Coder_Ex]

As it turns out what spawned the issue was not a result of any of the above.  My question should have been, I have three horizontal controls and the space between is not equal.  Coincidentally, the offset I was experiencing I though was being caused by shifting and losing the bits from odd numbers

            <<<<                                           800 pixels                                                      >>>>
BORDER < 32 pixel margin > <  FRAME > < 32 pixel margin > < DISPLAY AREA > < 32 pixel margin > BORDER
                                                              16 pixels to
                                                                CENTER

So you can see, the center of FRAME is actually @ 208 not 200 with a 800 pixel client area.

EDI = Pointer to the 4 parameters of CreateWindowEx x, y, nWidth, nHeight

Code Select Expand

mov eax, CenterLine
shr eax, 1
mov ecx, [edi + 8]
shr ecx, 1
sub eax, ecx
add eax, 8               ; Is what was missing and causing the problem
mov [edi], eax


[dedndave]

i hate it when i do that   :bg

i was wondering what you were doing - lol
if you have to do something "unnatural" like that, there is probably a reason - and a better way

[Tedd]

When you create a window, it's created with the size you give with the inclusion of any borders, menu, titlebar, etc. As a result, your client area will always be smaller.
If you want an exact size client area, use AdjustWindowRectEx to calculate the required window size.
http://msdn.microsoft.com/en-us/library/ms632667%28VS.85%29.aspx

The 'missing' pixels come from the border at either side of the window. Simple adding 8 will only work correctly on your machine (and any with the same settings; which is arguably most if it's the default.)

[sinsi]

My understanding of CS_BYTEALIGNx was that it was for 4-bit colour in win3 to avoid a window on an 'odd' pixel boundary.
8-bit and above are naturally on a byte boundary so this flag makes no sense.