News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Using AdjustWindowRect with a dialog box

Started by zedd151, March 15, 2025, 02:58:28 PM

Previous topic - Next topic

zedd151

#15
It is centering from left to right in the correct position.  :thumbsup:
But from top of screen to the top of the dialog box is 310 pixels.
From the bottom of the dialog box to the top of the task bar is 317 pixels.  :thdn:

Whoops. That was without the AdjustWindowRect call...

With AdjustWindowRect it is
from top of screen to the top of the dialog box is 290 pixels.
From the bottom of the dialog box to the top of the task bar is 297 pixels. wtf?
left-right centering is still correct.

Odd. Just odd...

A short  time later:
For completeness, I tested my original dialog template with my own resize and centering code.
The results are the same as using AdjustWidowRect.
top-bottom centering is off in my code as well, while left-right centering is perfect.
Maybe an issue with SystemParametersInfoA?? My original centering code also uses that function.

I had not checked this prior using my original code, I had just assumed that the dialog box was centered (at least +/- 1 pixel).

I am going to check my dialog box in the .rc file.
Maybe the window style is not WS_OVERLAPPEDWINDOW.... Will investigate and report my findings... that could be the problem.
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

zedd151

No, the dialog box window style in the .rc file was fine.

This issue is really driving me nutz!  :biggrin:
Both the latest 'resize and center using AdjustWindowRect' version, and the original 'homemade resize and center' version attached.
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

sinsi

Doesn't seem to be a problem here.
You cannot view this attachment.
Desktop working area is 1920x1032
832*2=1664, 1664+256=1920 so horizontally centred.
376*2=752, 752+279=1031 so vertically centred (1 pixel off because AdjustWindowRect adds 31 to the top).

zedd151

Are you taking into account that the task bar is not included in the desktop work area? If that is the case, I'm stumped.

I'll just leave it be, even if the height centering is not pixel perfect. But several pixels off for me.
I'm done with all of this.

Thanks for your help on this, btw. Now I gotta move on to other things.  :biggrin:
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

sinsi

Quote from: zedd151 on March 16, 2025, 09:30:12 AMAre you taking into account that the task bar is not included in the desktop work area
Quote from: sinsi on March 16, 2025, 09:17:28 AMDesktop working area is 1920x1032


zedd151

#20
Then I'm stumped.
I am going to run a simple test with a 'normal' Window, using the same methods used here, to see if using a dialog box is the issue for me.

If it too is off by more than one pixel on centering, than it is only a ME issue.  :rolleyes:
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

NoCforMe

Zedd: You're doing two things here, resizing the dialog window, and centering it on the desktop.

I haven't looked enough into your resizing code to be of any help. However, regarding the centering part, here's what I use in all my dialog-based programs to center the dialog on the desktop. It's simpler than what you're trying to do and works flawlessly.

I put these 3 statements in the dialog's WM_INITDIALOG code, and the rest is a small subroutine:
; Put this in your WM_INITDIALOG handler:
CALL GetDesktopWindow
INVOKE CenterDialog, EAX, hWin
INVOKE SetWindowPos, hWin, HWND_TOP, EAX, EDX, 0, 0, SWP_NOSIZE

;============================================
; CenterDialog (parentWinHandle, dialogHandle)
;
; Centers dialog on parent window.
;
; Returns:
; EAX = x-position for dialog
; EDX = y-position
;============================================

CenterDialog PROC parentWinHandle:HWND, dlgHandle:HWND
LOCAL gpRect1:RECT, gpRect2:RECT

INVOKE GetWindowRect, parentWinHandle, ADDR gpRect1
INVOKE GetWindowRect, dlgHandle, ADDR gpRect2
MOV EAX, gpRect1.right
SUB EAX, gpRect1.left
SHR EAX, 1
MOV EDX, gpRect2.right
SUB EDX, gpRect2.left
SHR EDX, 1
SUB EAX, EDX
ADD EAX, gpRect1.left
MOV ECX, EAX ;Stash x-pos.
MOV EAX, gpRect1.bottom
SUB EAX, gpRect1.top
SHR EAX, 1
MOV EDX, gpRect2.bottom
SUB EDX, gpRect2.top
SHR EDX, 1
SUB EAX, EDX
ADD EAX, gpRect1.top
MOV EDX, EAX ;y-pos.
MOV EAX, ECX ;Recover x-pos.
RET

CenterDialog ENDP

This code can be used to center any window over any other window, like when you open a second dialog from a main dialog.
Assembly language programming should be fun. That's why I do it.

zedd151

Thanks David, but I am not centering a dialog box on another window. I am using a dialog box as main window, and centering it on the desktop.

My code performs the same task as using AdjustWindowRect and SystemParametersInfoA. And both center the vertical but are both off by several pixels. Both meaning my code, and sinsi's method using AdjustWindowRect.

I have used all sorts of code to center Windows on the desktop in the over the years, this is the first time that I recall anything not centering properly.

When centered properly, either dimension should either be exact, or only off by one pixel(if the window or dialog box has an odd number of pixels in either dimension, or the 'work area'  has an odd number of pixels vertically).

Anyway, aside from running a couple if tests with window centering (not dialog boxes) to see if I get similar results, I am about done with all of this.

Maybe I am just too nitpicky.
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

NoCforMe

Quote from: zedd151 on March 16, 2025, 12:07:23 PMThanks David, but I am not centering a dialog box on another window. I am using a dialog box as main window, and centering it on the desktop.
Yes; you're centering your window (a dialog, which is a window) on another window (the desktop, which is also a window).

That's exactly what my code does.

It's all windows, all the way down ...
Assembly language programming should be fun. That's why I do it.

zedd151

Quote from: NoCforMe on March 16, 2025, 01:07:42 PMYes; you're centering your window (a dialog, which is a window) on another window (the desktop, which is also a window).
Ok.  :tongue:
I don't see how your code will do anything different than either my code, or sinsi's. Other than being a different method of performing the same task.
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

jj2007

There is a MoveWindow, hMain, 0, 0, 666, 444, 0 in the code, so the window should stick to the upper left corner. Guess what? It doesn't. It still did under Windows 7, IIRC :cool:

0       WinRect left
0       WinRect top
666     WinRect right
444     WinRect bottom
0       ClientRect left
0       ClientRect top
650     ClientRect right
385     ClientRect bottom




zedd151

Yes Jochen, I had used GetWindowRect in my original "resize and center" code, as shown in post #1.
sinsi had suggested AdjustWindowRect rather than my method.

Upon closer inspection, the dialog box is not exactly centered +/- 1 pixel in both directions as it should be. On the vertical, there is a discrepancy for me, no matter which method I had tried. The client area size is always correct after adjustments.

The dialog box is always 3-4 pixels higher than where it should be.

I have given up altogether since in the grand scheme of things, it is only a minor detail only noteworthy for nitpicky, OCD prone guys like me.  :biggrin:

The desktop window is always at 0, 0 which is what I am centering the dialog box on. Hope this clarifies a bit.
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

jj2007

The point is that since Windows 10 the sizing zone left & right (but not on top) is outside the visible window. Microsoft plays tricks on us :cool:

zedd151

Quote from: jj2007 on March 17, 2025, 12:21:35 AMThe point is that since Windows 10 the sizing zone left & right (but not on top) is outside the visible window. Microsoft plays tricks on us :cool:
Ok. Possibly due to the Metro interface?

I'm gonna test some of the code here on Windows 7... That will take a while, since I don't currently have it on either computer. It only takes 5-7 minutes to get it up and running.... but real life may get in the way...
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—

zedd151

#29
Quote from: jj2007 on March 17, 2025, 12:21:35 AMThe point is that since Windows 10 the sizing zone left & right (but not on top) is outside the visible window.
Also the alignment vertically is also affected.
I tested the same program on both windows 10 and windows 7.

On windows 7, lo and behold, centering is as perfect as it can get (within +/- 1 pixel).  :thumbsup:
On windows 10, however the dialog box is indeed higher by a few pixels.  :rolleyes:

Windows 7


windows 10


Thanks Jochen. If you would have mentioned this yesterday, woulda saved me a lot of trouble, and hair. (Been figuratively 'pulling my hair out' trying to figure out this discrepancy)  :tongue:

Now I know I can simply disregard any slight off-centeredness from now on, most likely not any error in the code, but Windows 10's fault.

Now the big question is, "is the misalignment always the same number of pixels, or does vary by screen size?" Testing will need to be done by those with huge "home theatre sized" monitors,  down to a monitor with 1024x768 screen dimensions.

Program tested also attached. You may need to adjust the following parameters for your screen size. For the test, I incremented these parameters so the dialog box just kissed either the top of screen, or top of the task bar. This was done to clearly see how exacting the vertical centering was, or not, at a glance without having to open the screenshot in paint and zoom in.
cwidth        equ 820  ; desired client area width
cheight      equ 820  ; desired client area height
¯\_(ツ)_/¯   :azn:

'As we don't do "requests", show us your code first.'  -  hutch—