Different nHeight() for same Dialog

[patrickmast]

Hi,

I have something strange. Please concider this code:

Code: Select all  Expand view  RUN

#include "FiveWin.ch"

FUNCTION Main()

   LOCAL oDlg

   DEFINE DIALOG oDlg TITLE "Test" FROM 0,0 TO 310,530 PIXEL

   @ 1, 2 SAY oDlg:nHeight OF oDlg
   @ 2, 2 SAY oDlg:nWidth OF oDlg
   
   ACTIVATE DIALOG oDlg CENTERED ON PAINT TestXY(oDlg)

RETURN NIL
                 
//-------------------------------

PROCEDURE TestXY(oDlg)

oDlg:SetText( Str(oDlg:nHeight,3,0) +","+ Str(oDlg:nWidth,3,0) )

RETURN

The nHeight en nWidth that comes from the "ON PAINT TestXY(oDlg)" is different than the one in the "@ 1,2 SAY oDlg:nHeight Of oDlg".

How can I make them the same?

I discovered this when my buttons on my dialog, which are painted based on the height of the dialog, was placed different on a Vista machine than on a WindowsXP machine.

The nHeight that is in "@ 1,2 SAY..." is the same on Vista or XP, but the nHeight of the "ON PAINT.." is different on Vista than on XP.

So, I have to find a way that the nHeight() of a Dialog is the same on Vista or XP.

Please try the sample, it makes it so much simpler to explain

Patrick

[James Bott]

Patrick,

>The nHeight that is in "@ 1,2 SAY..." is the same on Vista or XP, but the nHeight of the "ON PAINT.." is different on Vista than on XP.

When you use @1,2 you are using row,col coordinates which are based on the old DOS screen of 25 rows, 80 columns. The ON PAINT is using pixels.

The difference you are seeing between XP and Vista is probably because the screen resolutions are set different.

James

[patrickmast]

When you use @1,2 you are using row,col coordinates which are based on the old DOS screen of 25 rows, 80 columns. The ON PAINT is using pixels.

Sorry but you must have misread my question. Its not the @SAY coordinates I need, but the coordinates of the dialog. if you run the sample, you will see

The difference you are seeing between XP and Vista is probably because the screen resolutions are set different.

No, it's not. The dialog should be the same height regarding the screen size. Otherwise, we need to build different dialogs per resolution right.

James, please run the sample and you will see my problem.

Patrick

[Otto]

Patrick, it seems
oDlg:nHeight is returning the client rectangle.
Regards,
Otto

[patrickmast]

Patrick, it seems oDlg:nHeight is returning the client rectangle.

Otto, thanks for pointing that out. Now, why is it different in XP versus Vista?

Look at this. Same exe, run in XP and in Vista:


This is why my buttons (based on the calculation of oDlg:nHeight() ) are placed different in XP than in Vista..







Patrick

[James Bott]

Patrick,

>This is why my buttons (based on the calculation of oDlg:nHeight() ) are placed different in XP than in Vista..

Perhaps because the title bar and borders are slightly different sizes in the two different themes?

Is there a reason you are not using dialogs defined as resources?

James

[patrickmast]

Perhaps because the title bar and borders are slightly different sizes in the two different themes?

Don't know. Antonio, can you help?

Is there a reason you are not using dialogs defined as resources?

Yes. If we want to build our app for a different OS, its easier not to use resource as not every OS can use RC's. That's why I try to use as much @ x,y's as possible.

Now, even if this is not a good reason NOT to use RC's, it is still something that should be fixed

Thanks!

Patrick

[James Bott]

Patrick,

Here is something else to keep in mind. This is a quote from an article about coding for dialogs:

"DIALOG is the resource type, and the four number are the Left, Top, Width and Height co-ordinates. These ARE NOT PIXELS, they are in Dialog Units, which are based on the size of the font used by the system (and chosen by the user). If you have a large font selected, the dialog will be large, if you use a smaller font, the dialog will be that much smaller. This is important as it makes sure that all of the controls are the proper size to display their text in the current font. You can convert dialog units to pixels at runtime using MapDialogRect()."

The complete article is here:

http://www.winprog.org/tutorial/dialogs.html

You can also find more information by Googling "dialog units."

So, the short answer is that "fixing it" probably will require that you code it differently--and perhaps differently for different OSs.

James

[Antonio Linares]

Patrick,

James is totally right: When you define the dialog we are using "dialog" units, but when the dialog is already created, windows calculates the final "pixel" units, based on the used font.

You should always use oDlg:nWidth() and oDlg:nHeight() from the ON INIT clause of the dialog, as there you have the real pixel sizes.

Please review the Windows API docs for GetDialogBaseUnits():
"The GetDialogBaseUnits function returns the dialog box base units used by Windows to create dialog boxes. Both Windows and applications use these units to convert the width and height of dialog boxes and controls from dialog units, as given in dialog box templates, to pixels, and vice versa."

[Antonio Linares]

Patrick,

See these formulas from the Windows API docs:

The horizontal base unit is equal to the average width, in pixels, of the characters in the system font; the vertical base unit is equal to the height, in pixels, of the font. Furthermore, each horizontal base unit is equal to 4 horizontal dialog units; each vertical base unit is equal to 8 vertical dialog units. Therefore, to convert dialog units to pixels, an application applies the following formulas:

pixelX = (dialogunitX * baseunitX) / 4
pixelY = (dialogunitY * baseunitY) / 8

Similarly, to convert from pixels to dialog units, an application applies the following formulas:

dialogunitX = (pixelX * 4) / baseunitX
dialogunitY = (pixelY * / baseunitY

The multiplication is performed before the division to avoid rounding problems if base units are not divisible by 4 or 8.

[Antonio Linares]

After further reviewing it, it seems that the different values come from a different issue:

When we create the memory template to build the dialog, FiveWin uses GetWndRect(), and this may provide different values in XP and Vista, because it is not the client dimensions, it is the total dimensions including the title bar and the borders.

[patrickmast]

After further reviewing it, it seems that the different values come from a different issue:

When we create the memory template to build the dialog, FiveWin uses GetWndRect(), and this may provide different values in XP and Vista, because it is not the client dimensions, it is the total dimensions including the title bar and the borders.

Antonio,

Thank you for all the provided info.

Patrick