Re: vNoticeDialog centering bug report.
On Wed, 09 Dec 1998 00:51:13 +0100, Serguei DACHIAN
<Serguei.Dachian@univ-lemans.fr> wrote in :
>I think that the problem comes from using different coordinate systems. I'll
>try to explain it in more details. Here is a piece of code (which should
>normally center the notice) from "srcwin/vnotice.cpp" file.
>
>void vNoticeDialog::DialogDisplayed()
> {
> // center the dialog in the app window
> RECT rctApp, rctDlg; // app and dialog corners
> ::GetWindowRect(theApp->winHwnd(), &rctApp);
> ::GetWindowRect(_wDialog, &rctDlg);
> int widApp, htApp, widDlg, htDlg; // app and dialog dimensions
> widApp = rctApp.right - rctApp.left;
> htApp = rctApp.bottom - rctApp.top;
> widDlg = rctDlg.right - rctDlg.left;
> htDlg = rctDlg.bottom - rctDlg.top;
> int left, top; // new dialog upper-left corner
> if ( widApp > widDlg )
> left = (widApp - widDlg)/2; // don't add to left - SetDialogPosition does
> else
> left = rctApp.left;
> if ( htApp > htDlg )
> top = (htApp - htDlg)/2;
> else
> top = rctApp.top;
> SetDialogPosition (left , top); // set the position, in V coords
> }
This code won't work properly under Windows. The reason is a typical MS
problem. :)
When you retrieve the coordinates via GetWindowRect() then you get the
coordinates in absolute screen coordinates, what is quite ok. Calculating the
difference by subtracting the parent window only gives coordinates relative to
the outer frame of the respecive windows but the coordinates used by the
window itself are clientrectangle oriented. So you have to get the height of
the menubar and the width of the border in order to get the real client
coordinates. I stumbled over this when I wrote my CellView class for VGui and
I still have problems with this. I don't know why MS don't report client
coordinates when it uses it as input??? :(
>I think that the problem here is the following: what we get in "widApp" and
>"htApp"is the size of the "full" application window (i.e. the window
>including the status bar, titrle bar, etc.); but when the
>"SetDialogPosition" is called it sets dialog position with respect to "not
>full" (i.e. without status bar, command bar, etc.) window's upper-left
>corner, and NOT the "full" window's upper-left corner. So here the problem
>is !!! Unfortunately I don't know how to correct that, i.e. I don't know if
There are system constants you can retrieve with (I think but have to look it
up though) GetSystemMetrics(). The only problem with this approach is that you
have to know what kind of gadgets are between the outer border and the client
rectangle. In my class I circumvented this by reading the childwindow
coordinates, then I calculate the differences (as above) move the window to
the assumed clientcoordinates and reread the newposition. The new position of
the childwindow now reflects the width and height that the clientrectangle is
offest from the border without the need to know what there may be between it
(i.e. Menubar, Border, additional items like toolbars etc.). This is a little
awkward but it works. :)
>As to my mind, it makes NO any sense, since left and top are used with
>respect to the application's window, while rctApp.left and rctApp.top are
>measured with respect to the upper-left corner of the screen!!! I think it
>should rather be:
>> left = 0;
>and
>> top = 0;
Yes, but that is MS standards. :(
>or mayby it is better to put someting like 10 and 10 to make it more "nice".
That may work but only reliable on known configurations. If you install a
program that adds fancy buttons to each window your offset will be invalid
again.
BTW: Top is about 16 and left is about 2 but you can check it out with
GetSystemMetrics(constant). If you need the constants they are documented in
the MS books, but I can look it up if you don't have an MS compiler with the
appropriate documentation.
---
Bye,
Gerhard
email: sparhawk@eunet.at
g.gruber@sis.co.at
FIDO: 2:313/37.999
Spelling corrections are appreciated.
Torture your data until they confess. (Einstein?)
Reply to: