Dialog Units...uhhhhh...

[RyanCross]

Okay maybe I'm the only person, but I hate these Dialong Units in the DDT. I have to constantly keep converting Pixels to DU and DU to Pixels and it's starting to become a pain. I really think they should have atleast have a option to use Pixels or DUs when you make your Dialog or nix the DUs altogether. Twips are nice for a Visual Designer but with DDT I think sticking to Pixels would be a better idea.

-------------
Thank you,
Ryan M. Cross
Head Webmaster Nofee Inc. Internet Services
President Likuid Creations Ltd.

[E B Knoppert]

I go for twips..

------------------

[Chris Boss]

Ryan;

The problem with Dialog Units is that they are not equal to an exact number of pixels.

Horz. - 2 Dlg Units = 3 pixels (or 1.5 Pixels per Dlg Unit)

Vert. - 8 Dlg. Units = 13 pixels (or 1.625 pixels per Dlg. Unit)

As long as you stick to multiples of 2 x 8 Dlg. Units they will always translate into an exact number of pixels.

The problem is when you don't use multiples of 2 (Horz.) or 8 (Vert.) it causes the translation to pixels to not be exact. I am not sure how DDT "rounds" the Dlg. Units to Pixels, but you will find that at times it may be hard to get controls to line up or be the correct size, when you don't use the multiples I mentioned above.

Using multiples of the 2 X 8 Dlg. Unit Grid should always put your controls in an exact pixel location.



------------------

[Chris Boss]

Since you brought up the subject, there is an easy solution the problem with Dlg. Units, that I think it would be nice to add in the next version of PB.

If PB wants to stick with Dlg. Units, then they should make a simple change in all the DDT commands that define coordinates and size and width.

Convert the parameters (X, Y, Width, height) from Long Integers to Single (real - decimal) numbers.

This would allow us to define an exact pixel location in Dlg. Units, because you can define values with a decimal.

If 1 Dlg. Unit equals 1.5 pixels (Horz.) then you could define 2 pixels as 1.333 Dlg. Units.

To make the system even better, (besides using real numbers) it would be good to have a new command that allows us to define the Units in pixels with a command like:

Dialog DefUnit X&, Y&

If we wanted to work with Pixels then simply use:

Dialog DefUnit 1, 1

If we wanted to use standard Dialog Units then use:

Dialog DefUnit -1, -1

which would set it back to standard Dlg. Units.

If we wanted to use a character Grid (say 8 x 16 pixels) we could use:

Dialog DefUnit 8, 16



------------------

[RyanCross]

Okay I get what your saying now, but a lot of my buttons and other controls are owner-drawn so I have to use the Pixel Size of the bitmap to size the button, that's why its such a pain for me.

------------------
Thank you,
Ryan M. Cross
Head Webmaster Nofee Inc. Internet Services
President Likuid Creations Ltd.

[Chris Boss]

Ryan;

I can see your problem. You have to get the button control to be the correct Pixel size, because you are drawing them yourself.

What I would do is create a simple Function (or Procedure) that will Resize the control to what you want using the API.

Sub ResizeControlByPixel( hDlg&, ID&, W&, H&)
Local hCtl&, Flag&
CONTROL HANDLE hDlg&, ID& TO hCtl&
Flag&=%SWP_NOMOVE or %SWP_NOZORDER or %SWP_NOACTIVATE
SetWindowPos hCtl&, 0, 0, 0, W&, H&, Flag&
End Sub

Call this procedure after each Button is created to correctly resize the control by Pixels.


------------------

[Lance Edmonds]

It is perfectly acceptable to use the GetWindowRect() and GetClientRect() API calls to get the size of a DDT control (or dialog) in pixels. Similarly, you use the GetDlgItem() to get the handle from the ID. Combining these functions provides another way to get the pixel size instead of using DIALOG UNITS...TO PIXELS, etc.




------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Dominic Mitchell]

The problem with Dialog Units is that they are not equal to an exact number of pixels.

Horz. - 2 Dlg Units = 3 pixels (or 1.5 Pixels per Dlg Unit)

Vert. - 8 Dlg. Units = 13 pixels (or 1.625 pixels per Dlg. Unit)

This is misleading. While the above is true for the DEFAULT_GUI_FONT(MS Sans Serif,
8 point, FW_NORMAL)(average width = 6 pixels, average char height = 13 pixels), it will
not hold true when you use a different font with DS_SETFONT specified. For example,
12 point MS Sans Serif (average char width = 11 pixels, average char height = 20 pixels)
yields
Horz. - 2.75 pixels per base dialog unit
Vert. - 2.5 pixels per base dialog unit


------------------

[Chris Boss]

Dominic;

The 2 x 8 Dlg. Unit Rule should always work with a DDT Dialog, since DDT does not allow you to use a different font (other than MS Sans Serif) in the creation of the Dialog. While you can change the font for a Dialog using WM_SETFONT, this shouldn't change the Dialog Units which are defined the moment the Dialog is created (not displayed).

The %DS_SETFONT style is not listed in the PB Docs for Dialog New, so I doubt you can change the Font during the creation of the Dialog (which would affect Dialog Units).

You are correct, if the Dialog is created using a Dialog in a Resource which uses DS_SETFONT or when you use a memory Template of a Dialog to create it.

My discussion above applies only to DDT.


------------------

[Chris Boss]

This discussion brings to mind a question about DDT, which I would like to ask the guys at PB:


Is it possible to Create a DDT Dialog with a different default font (like using DS_SETFONT with an API Dialog), which would obviously change the Dialog Units as mentioned by Dominic ?

It doesn't look like DDT supports the DS_SETFONT style and likely DDT does some things under the hood differently than the normal Dialog Creation engine in Windows.

What will happen if DS_SETFONT is used with a DDT Dialog ?

Where would you define the new font and would this affect the Dialog Units in the DDT Dialog ?

I know there is a difference (with the API) between using the DS_SETFONT style (which does affect Dialog Units) and sending the WM_SETFONT message after the Dialog is created.

What Dominic said is absolutely true with API created Dialogs, but I need to know what happens with DDT in this situation.


------------------

[Chris Boss]

Ryan;

The above function I posted for Resizing a control will NOT be affected by the actual size of the Dialog Units.

The function uses Pixels (not Dialog Units) and it will only resize the control, but not move it.

It should solve your problems.

------------------

[Semen Matusovski]

Hmmm ....
I always thought, that to use such relations as
Horz. - 2 Dlg Units = 3 pixels (or 1.5 Pixels per Dlg Unit)
Vert. - 8 Dlg. Units = 13 pixels (or 1.625 pixels per Dlg. Unit)
even with DDT is enough dangerous.
DDT asks MS Sans Serif, 8pt, but who can garantee that such font is present and that in future Microsoft will not change this font ?
I think that only MapDialogRect (eq. Dialog Units <> Pixels ?) gives correct answer in any case.

------------------

[Chris Boss]

There is a problem in calculating how many Pixels in a Dialog Unit (exactly).

The problem is that both DDT and the API return the answer back with a Long Integer, rather than a Real number( with a decimal).

Lets look at the Math:

Vert. - 8 Dlg. Units = 13 pixels (or 1.625 pixels per Dlg. Unit)

If I multiply 99 Dlg. Units / 1.625 (pixels/per) I get 160.875

You have to round the number off which is either 160 or 161.
Using DDT or the API you will get either 160 or 161 back.

Now if you were to calculate the number of pixels per Dialog Unit using 99 Dlg. Units as a test number, then you would get one of two answers:

160/99 = 1.616161 pixels/Dlg. Unit

or

161/99 = 1.626262 pixels/Dlg. Unit


neither is correct since it is actually 1.625 pixels/Dlg. Unit

Any calculations of Pixels from Dialog Units will always be slightly off and as Ryan problem shows, a pixel off here or a pixel off there can mean a lot in some instances.

This means that if you want "exact" measurements, you must use Pixels (or a Dialog Unit that divides evenly into Pixels - unlikely).

Ryans solution is to use the API to resize the controls to exact pixel dimensions.

Until there is some kind of Decimal method of defining values in Dialog Units, it will never be 100% accurate.

Now Twips wouldn't be all that bad an idea since there is 1440 Twips per Inch, which would mean that Twips are so small that it is almost like having a decimal to work with. There are many Twips in a Pixel and rounding would be easier.

I prefer pixels, since they are absolute.

The reason I came up with the 2 X 8 Dlg. Unit grid mentioned above (3 x 13 pixels), is because of the DDT Visual Designer I am working on. My Visual Designer works with Pixels under the hood. Even though it actually uses "character" coordinates, the characters are always defined as a number of exact pixels and the Visual Designer uses Real Numbers, not Integers to hold the values. I can define an exact pixel location using a decimal.

The problem I was having was that the coordinates did not convert perfectly when I converted them to DDT values (I create the Dialog using CreateDialogIndirectlparam with the MS Sans Serif 8 point font, so it matchs the Dialog Units in DDT created Dialogs). Translating Pixels to DDT Dlg. Units would sometimes make controls a pixel off here or a pixel off there.

I solved the problem by finding the common denominator between Dlg. Units and Pixels (2 X 8 Dlg. Unit Grid) and the controls always line up now. The Visual Designer warns you that if you do not use the 2 X 8 grid or multiples of it (you can use a 1 x 1 pixel or 3 x 3 pixel grid) that the translation of Pixels to Dlg. Units may be off a hair.

In most instances its not a big deal (a pixel here or a pixel there), but in some instances it may be.

I am not overly concerned about the Grid size changing since the MS Sans Serif font is a "System" font which comes in all versions of Windows the likely hood of a system font being changed signifcantly is small (a risk I have to take).

My Visual Designer uses the DDT commands to read the locations of the controls in Dlg. Units. I don't calculate the coordinates using the above arithmatic. I only use them for defining the "Snap to Grid" which will hurt little and only help.



------------------

[jcfuller]

Chris,
What happens if someone has large fonts selected in the
Display properties setting?

James


------------------


[This message has been edited by jcfuller (edited March 30, 2000).]

[Chris Boss]

James;

I'll have to test that !

I doubt DDT is using the system defined font, but likely it creates its own Ms Sans Serif 8 point font.



------------------

[Dave Navarro]

Is it possible to Create a DDT Dialog with a different default font

No.

At this time, DDT is not set up to allow you to specify your own font. That's on the list for a change in the next version.

--Dave


------------------
PowerBASIC Support
mailto:[email protected][email protected]rbasic.com</A>

[Chris Boss]

James;

I tested out changing to the Large font and

it does affect the Dialog Unit conversion !

My DDT Dialogs come out a different size when the Large font is selected.

Back to the drawing board !

I think I need to find an API call to find out what the percent value is for the size of fonts (Large Fonts is 125%) and add a fudge factor.

The value of Dialog Units is that they automatically resize no matter what size font is used by the system.

The problem is you can't count Pixels and be absolutely accurate.



------------------

[Chris Boss]

Thanks to James question about the affects of using the Large Font rather than Small Font, I did some research and found out an interesting thing.


Q. First, how do we know which Font setting is being used by the end user ?

A. Using the following code:

hDC& = GetDC(%HWND_DESKTOP)
PPI&=GetDeviceCaps(hDC&, %LOGPIXELSY)
ReleaseDC %HWND_DESKTOP, hDC&
if PPI&=96 then
    ' This is Small Fonts
elseif PPI&=120 then
    ' This is Large Fonts
else
    ' This is a custom Font Size Setting
    ' PPI& equals the number of Pixels per Inch
end if

Q. How are fonts affected by this ?

A. The above use of GetDeviceCaps(hDC&, %LOGPIXELSX) (Pixels per Inch) is used in the calculation needed to convert Point size to Logical Size before calling the CreateFont function.
This means you will calculate your created Fonts size based on the Pixels per Inch value determined by which Universal Font size is selected. Windows is forcing you to automatically scale your fonts in your apps.

This also means you can avoid the scaling of fonts by simply using 96, rather than the return value from GetDeviceCaps.

Q. What does this mean for DDT ?

A. Nothing, because DDT does not let you override this calculation because it is only defining MS Sans Serif 8 PT, but it does not let you modify the calculation of the Logical Font size (used internally by CreateFont).

Q. Does this affect the 5 predefined Fonts in windows (stock Items) ?

A. Likely yes ! The predefined Fonts, System, System Fixed, Default GUI, OEM, etc. are likely scaled automatically when Windows starts up. This would mean that using them in your app will force them to be scaled when the end user selects Large Fonts.


Now, that I have figured this all out, I need to impliment some better control in both Exxxx (Dreaded E word) and in my DDT Visual Designer when it comes to both fonts and Dialog coordinates.



------------------

[Steve Hutchesson]

To address Ryan's original concern, Dialogs (PB or Native Windows) are
scaled depending on what font is used with the dialog. The reason for this
Dialog style behaviour is so that the dialog auto-rescales on the basis of
the font size so it displays correctly on different machines that have
different font sizes.

The alternative is to use CreateWindowEx() windows and controls which work
in device units (pixels) and code the scaling yourself. Any form of
conversion in units is ALWAYS converted back to device units for display
purposes.

Now the problem with using bitmap images is that they are ALWAYS in device
units so you have the choice of rescaling them with StretchBlt() or
resizing the control that the bitmap is placed on. Most people opt for
using dialogs because it does the scaling automatically for you but with
CreateWindowEx() calls, you can directly fit bitmaps to controls with no
problems.

Twips are basically printer based logical units which is fine if you are
setting up a window to print its contents but just another conversion when
you need to display something on the screen.

Most CreateWindowEx() style applications do a least some rescaling with
things like status bar heights, title bar sizes and of course, the system
defined colours and it is normal to calculate the size of the client are
of a window before placing another window in the client area.

Fortunately, there is a range of options available for windows programmers
depending on the application type.

Regards

[email protected]

------------------

[Lance Edmonds]

Just to "muddy the waters": The problem with using a "fudge-factor" when translating Dialog Units to Device Points is that it is possible to define an _arbitary_ font scale other than the 125% (large font size) offered by Windows - I'm not sure if Windows 98 allows this, but Windows 2000 does.

The concept of using dialog units is that you are relying on windows to perform the scaling to device units. Reverse engineering this translation accurately means that you have to follow the algorithm Windows uses. Because Device Points are whole numbers, you will *always* have the problem of rounding effects when translating between these two scales.

My 2% of $1.00


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>