Dialog Units - Topic Continued !

[Chris Boss]

Ok, with some very appreciated help from Eric Pearson and a few hours reading everything I can about Dialog Units (especially the Microsoft Docs on the web), I would like to continue the discussion.

Dialog Units are obviously very important because they allow our Dialogs to "scale" based on the end users setting for the Font size (Small fonts versus Large fonts).

Microsoft obviously recommends that all Windows app be "scalable".

Heres the specs for Dialog Units (as far as I can tell):

There are actually two Dialog Units according to the MS docs:

(1) The Dialog Base Unit which is :
Horz. Base Unit = average width of the Dialogs Font
Vert. Base Unit = average height of the Dialogs Font

(2) The Dialog Template Unit which is:
(The actually Dialogs Units we work with)
Horz. Template Unit = 1/4 Base Horz. Unit
Vert. Template Unit = 1/8 Base Vert. Unit

Now the problem with Dialog (Template) Units is that they don't match up exactly with pixels.

The Dialog Base Units for the MS Sans Serif, 8 , font is:
(in Small Font mode)

Horz. = 7 pixels (BaseX)
Vert. = 13 pixels (BaseY)

(System Font is 9 X 16)

Now a Dialog Template Unit is 1/4 BaseX and 1/8 BaseY.

1/8 of 13 is 1.625 pixels per Dialog Unit (Vert.)
1/4 of 7 is 1.75 pixels per Dialog Unit (Horz.)

Now the problem is that if the Dialog (Template) Unit does not equal an exact number of pixels the translation can lose something. Windows has to round the Dialogs Units to the closest Pixel. This means that it is not accurate at the Pixel level. To gain scaling, you lose accuracy.

Now as far as I can tell, the only way around this would be to be able to use a Real number for the Dialog Unit. This way an exact Pixel location could be defined as a Dialog Unit, but you wouldn't lose the scaling feature.

Another possible solution would be to use "Twips". While it has been suggested that Twips are only for use with the Printer, I find it intriguing that Visual Basic uses Twips as the core coordinate system in its Form (file) format.

The advantage of Twips is that Twips are so small, they are "like" using a real number.

You see, Dialogs Units are usually "bigger" than pixels, so the pixel is the smaller of the two Units. Twips on the other hand are much smaller than Pixels (15 Twips per Pixel and 12 in Large Font mode). Because they are so small, you can always define an exact number of pixels in Twips. Twips are also scalable like Dialog Units.

Why I am so concerned about Dialog Units ?

Since the use of a "scalable" unit of measure is important in Windows apps (aka. Dialog Units) any Visual Designer for PB requires that it understand and work correctly with this type of unit of measure. Its no fun if you design a Dialog Visually and then when you generate the code it is not the same size as it was in the Visual Designer.

Any comments (and suggestions for dealing with the problem of conversion between Dialog Units and Pixels) are appreciated.

The above discussion should apply equally to DDTs use of Dialog Units

DDT uses the MS Sans Serif, 8 point font for Dialog Boxes.



[This message has been edited by Chris Boss (edited April 04, 2000).]

[Chris Boss]

Code removed since it was copied from MSDN web site !


[This message has been edited by Chris Boss (edited March 23, 2003).]

[Cecil Williams]

Chris,

You've done a real good job on this subject. However one thing does puzzle me. Being somewhat new to the Windows arena, I didn't quite understand how a "SUB" would return a value unless you were using STATIC variables as the first two parameters in the procedure above.

Further info can be found at the following link:
HOW TO: Calculate Dialog Units When Not Using the System Font http://support.microsoft.com/support.../Q145/9/94.ASP

This link also gives an alternative way to get the pixel value you are looking for.

Cheers,
Cecil


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

[Lance Edmonds]

The first two parameters are being passed by reference (BYREF) therefore the calling code will receive the values into the variables used as parameters in the call. BYREF means that the compiler actually passes a pointer to the memory where the variables are stored - any changes to these memory addresses will show up in the calling code.

Conversely, the 3rd parameter is passed BYVAL. If a variable is used for this parameter in the calling code, it will not be changed by the code within the sub.

Please review the help file for more information on BYVAL, BYREF and BYCOPY... the section in the help file on "CALL" covers this information quite well.

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

[Chris Boss]

The story does get more Interesting !

As I mentioned above, the average width of the MS Sans Serif, 8 Point font (Small Font mode) comes out to:

7 x 13 pixels

The actually value is about 6.7 and the compiler rounds it to 7 (rounding is used when converting a single to long).

This seems to be the same as what the Windows Dialog Editor uses, which I assume uses the same formula as recommended by the MS Docs (listed above).

(Note: I should have added code to select the old font handle back into the desktops DC).

Now DDT seems to use a slightly different method of calculating the Base Unit (which a Dialog Unit is based on , either 1/4 (X) or 1/8 (Y) of it). DDT uses a base unit of 6 pixels (width) rather than 7.
I don't know what is inside of DDT, but it is possible it uses a calculation like this:

BaseX&=SZ.cx/52 (which would be the logical way to do it)

rather than

BaseX&=(SZ.cx/26+1)/2

If you use the formula , BaseX&=SZ.cx/52, the Base Unit width of the MS Sans Serif font, 8 point comes out to about 6.2 which the compiler will round to 6, rather than 7.

Either DDT uses this formula or the calculation is done with only Longs (no reals) so no rounding occurs and the value is the lowest inetger.

So now the question, which method should I use ?

If you are writing an app using SDK style code, then I would recommend , BaseX&=(SZ.cx/26+1)/2, since this comes straight from the Microsoft Docs. This would make your calculations round off to a number that windows would normally do.

If you are writing an app with DDT or that needs to be compatible with DDT, I suggest using the second , BaseX&=SZ.cx/52, since you will get a value more like what DDT calculates.

I have had actually had to use "both" methods in my EZGUI engine. By default EZGUI will use the first method to calculate the BaseX value to make it compatible with standard windows stuff. But I also have functions for calculating it using the second method, so I can use them in the DDT Visual Designer I am building. Previously, I was using DDT commands to get the locations and sizes of the control , to generate code. Now, I can use my own functions and "they do come out correct".

I can also convert Twips into Character coordinates (with my system) and then to Dialog Units for DDT, when Importing VB Forms into the DDT Visual Designer.

This discussion is important to anyone who is developing a Visual Designer for PB. It is not enough to be able to work with Pixels in a Visual Designer. You will need to use Dialog Units (or at least convert) and you will have to handle the Snap to Grid features with techinques that will undersand the variations caused by using the Dialog Unit, rather than a pixel (not easy).



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

[Chris Boss]

Another note:

There are some good "code generators" out there for converting both VB Forms and RC files to DDT. Since there is a slight variation between a DDT Dialog Unit and one created by a Resource Dialog Editor (as far as I can tell. This is the 6 pixel versus 7 pixel discussion above for a Base Unit), it would be good to make modifications in the code so they generate a DDT Dialog that is 100% identical to the one from VB or the Dialog Editor.

I have tried every code generator posted on this forum and some of them (especially the VB ones) produced a DDT Dialog that was not the same size as the original. Using the above info should others solve these difficulties .

In the DDT Visual Designer I am working on I will create the Dialog, generate the code, run the DDT program created and then display the DDT programs Dialog right next to the Visual Designers version of the Dialog and then compare them to see if they are identical. So far so good.


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

[Cecil Williams]

Lance,

I understand what was going on, I just didn't recognize it at first. I'm so accustomed to functions returning values that I did not see that in effect, the SUB was doing the same thing.

Cheers,
Cecil

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