Announcement

Collapse
No announcement yet.

Dialog Units...uhhhhh...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chris Boss
    replied
    Thanks for the info Eric !

    I have already modified the EZGUI 1.1 beta (which will be EZGUI 2.0 when released) to take advantage of Dialog Units.

    EZGUI uses a Character based coordinate system, but version was defining the character size as 8 x 16 pixels (which could be changed in code).

    EZGUI 2.0 will use a character size which is "calculated" based on Dialog Units.

    A Dialog Unit is:

    (Horz.) 1/4 of average width of Dialogs font
    (Vert.) 1/8 of height of Dialogs font

    Dialogs Units are based on the average width amd height of the Dialogs font, so EZGUI 2.0 will use a Character size of:

    (Horz.) 4 Dialog Units
    (Vert.) 8 Dialog Units

    EZGUI defines the Character Coordinates as real numbers, so you can define a coordinate of say .25 which would be 1 Dialog Unit (Horz.). This will allow using Dialog Units (actually Dialog Characters) for autoscaling, but it will allow greater precision.

    Thanks for all the info, since it will help me make a better product and it will help me have better compatibility with DDT. My DDT Visual Designer is an EZGUI app, so the new autoscaling based on Dialog Units will be necessary for DDT Dialog Design.



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

    Leave a comment:


  • Eric Pearson
    replied
    Ignoring VB for the moment... Off the top of my head (and without knowing for sure) I'd speculate that the default scaling unit for Visual C++ is Dialog Units, since the Visual Studio resource editor is used for creating a UI. And the Win32 API works with Dialog Units, as does DDT... IMO, EZGUI should use Dialog Units, not Twips. Twips are more of a printer thing.

    Just my opinion.

    -- Eric

    ------------------
    Perfect Sync: Perfect Sync Development Tools
    Email: mailto:[email protected][email protected]</A>

    Leave a comment:


  • Chris Boss
    replied
    Eric;

    Thank You !

    The MS Docs are very informative !

    From what I read, it almost appears that "any" use of Screen Units (Pixels) for designing a Dialog is a No, No.

    This seems very strange to me, since Dialog Units don't translate exactly to an exact number of pixels (1 to 1 correlation), which is what is needed for accuracy at times.

    The only "accurate" Units, I can think of would be "Twips" since they are so much smaller than Pixels, that they would convert well to pixels.

    Twips are 1440 Units per Inch.

    The standard display uses 96 pixels per "Logical Inch", so you would have 15 Twips per Pixel.

    So there may be evidence of the value in using Twips after all.

    Obviusly there must be some valid reason for using Twips, because Twips are the default coordinate system for Visual Basic. Even when you use a Scalemode of Pixels in a VB Form, the Forms code (in the FRM file) still uses Twips for Units (not Pixels).

    VB Forms do autosize, based on the system Font Size (large or small), just like Dialogs do.

    From what I am learning, I may even seriously consider changing the coordinate system in EZGUI 2.0.



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

    Leave a comment:


  • Eric Pearson
    replied
    Chris --

    Here is an interesting MSDN page, called "Large Fonts Versus Small Fonts Use in Windows".

    http://support.microsoft.com/support.../Q177/7/95.ASP

    Here is a pertinent quote: "Applications should not attempt to determine the system font size since there is no reliable way to obtain the information.

    Also: LOGPIXELSX and LOGPIXELSY values (...) not reliable...

    -- Eric

    ------------------
    Perfect Sync: Perfect Sync Development Tools
    Email: mailto:[email protected][email protected]</A>

    Leave a comment:


  • Chris Boss
    replied
    Lance;

    The above code I posted that uses GetDeviceCaps returns the custom font size value as well.

    Small Fonts = 96 (pixels/Inch)
    Large Fonts = 120 (pixels/inch) (which is 125% of 96)

    If a custom Font size is selected , the pixels/inch value is returned.

    The reason for using this function, is that sometimes you may not want Windows to autoscale your Forms/Fonts. Autoscaling may not always be wanted.

    A problem occurs with autoscaling of Fonts, when you create a Dialog that is not autoscaled, but the fonts get scaled and the text is too big for the buttons.

    Some who write apps using SDK style code or EZxxx (dreaded E word) may create Windows that are not autosized, like Dilaogs are. If the Fonts get autosized, then they may be too big for the controls (like Buttons). There needs to be a way to "force" Windows to not autosize the Fonts.

    As it turns out, the GetDeviceCaps function is used in the "pre-calculation" of the logical Font size (convert from Points (1/72 inch) to Logical Units for the CreateFont function) and this makes your fonts "autoscaled". By substituting the value 96 (smallfonts) for the return value of GetDeviceCaps, your fonts will not be autoscaled.

    While some apss may be better having autoscaling, some apps may not look right. What happens if you create a Window that has lots of controls and was designed to fill an 800 x 600 screen. If it got autosized, it would be bigger than the screen. While smaller popup Dialogs won't be a problem with autosizing, Dialogs that use the entire screen (like a Data input screen for a business app), would be too large.

    IMO, it is better to give the programmer the choice to allow autosizing or not.




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

    Leave a comment:


  • Semen Matusovski
    replied
    It's enough to replace Dialog New and Dialog Show by own subroutines and appears full freedom.
    Just my 2 cop. = 0,06 c (not more)



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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Steve Hutchesson
    replied
    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]

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

    Leave a comment:


  • Chris Boss
    replied
    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:
    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.



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

    Leave a comment:


  • Chris Boss
    replied
    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.



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

    Leave a comment:


  • Dave Navarro
    replied
    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]</A>

    Leave a comment:


  • Chris Boss
    replied
    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.



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

    Leave a comment:


  • jcfuller
    replied
    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).]

    Leave a comment:


  • Chris Boss
    replied
    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.



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

    Leave a comment:


  • Semen Matusovski
    replied
    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.

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

    Leave a comment:


  • Chris Boss
    replied
    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.

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

    Leave a comment:


  • Chris Boss
    replied
    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.


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

    Leave a comment:


  • Chris Boss
    replied
    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.


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

    Leave a comment:


  • Dominic Mitchell
    replied
    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


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

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:

Working...
X