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).]
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).]
Comment