Announcement

Collapse
No announcement yet.

What is a Dialog Unit

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

  • What is a Dialog Unit

    As I understand the documentation, the "dialog unit" is the
    count of characters to be displayed. I'm trying to compute
    the size of the box based on the LEN of the text being
    displayed. But it seems necessary to do some computation
    on the size to even get close, e.g. 7*(L+1) as below. What
    am I missing. I'd like the code to work on any display, and
    I'm a little worried about just developing a empirical formula
    using my display 24 inch display.
    --------------------------------------------------------------
    $COMPILE EXE
    $INCLUDE "WIN32API.INC"
    FUNCTION PBMAIN()
    DIM List(1:10) AS STRING
    LOCAL i AS LONG
    LOCAL hDlg AS LONG
    LOCAL L AS LONG
    FOR i=1 TO 10:
    IF i>1 THEN List(i)=List(i-1)
    List(i)=CHR$(64+i)+CHR$(64+i)+List(i):NEXT i
    DIALOG NEW 0,"This tests the width of dialog boxes",,,320,240,%WS_CAPTION OR %WS_SYSMENU,0 TO hDlg
    L=2
    FOR i=1 TO 10
    CONTROL ADD COMBOBOX,hDlg,200+i,List(),10,5+i*16,7*(LEN(List(i))+1),11*10,%CBS_DROPDOWNLIST+%WS_TABSTOP
    COMBOBOX SELECT hDlg,200+i,i
    NEXT i
    DIALOG SHOW MODAL hDlg
    END FUNCTION

  • #2
    Joe --

    Here is a quote from the Microsoft Win32.HLP file:

    Every dialog box template contains measurements that specify the position, width, and height of the dialog box and the controls it contains. These measurements are device independent, so an application can use a single template to create the same dialog box for all types of display devices. This ensures that a dialog box will have the same proportions and appearance on all screens despite differing resolutions and aspect ratios between screens.

    Dialog box measurements are given in dialog base units. One horizontal unit is equal to one-fourth of the average character width for the system font. One vertical unit is equal to one-eighth of the average character height for the system font.


    So an average character displayed in the system font will be 4 dialog units wide. W will be wider, and I will be narrower. Basically, Dialog Units are used so that Windows will "scale" your dialog when the screen resolution changes, and (roughly) the same number of characters will be displayed in the available space.

    When the screen resolution changes, Windows automatically changes the size of the system font. So basing the size of your dialogs on the size of the system font is a good technique.

    You can convert from pixels to dialog units (and back) by using the PB/DLL DIALOG UNITS and DIALOG PIXELS functions.

    -- Eric

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



    [This message has been edited by Eric Pearson (edited January 26, 2000).]
    "Not my circus, not my monkeys."

    Comment


    • #3
      Thanks Eric, the reference helped. I should have looked in WINHLP32.
      The closest I could come was 4*LEN(S)+24. Test cases shown below. Knowing
      Microsoft's meaning of "average character width" would help improve the
      display, but I guess this is close enought for government work.
      -----------------------------------------------------------------------
      $COMPILE EXE
      $INCLUDE "WIN32API.INC"
      FUNCTION PBMAIN()
      DIM List(1:10) AS STRING
      LOCAL i AS LONG
      LOCAL hDlg AS LONG
      LOCAL L AS LONG
      LOCAL x AS LONG
      LOCAL w AS LONG
      LOCAL a AS LONG
      LOCAL b AS LONG
      a=4:b=24
      FOR i=1 TO 10:
      IF i>1 THEN List(i)=List(i-1)
      List(i)=CHR$(64+i)+CHR$(64+i)+List(i):NEXT i
      DIALOG NEW 0,"This tests the width of dialog boxes",,,320,240,%WS_CAPTION OR %WS_SYSMENU,0 TO hDlg
      CONTROL ADD LABEL,hDlg,-1,"Empirical caculations is "+STR$(a)+"*StringLength+"+STR$(b),0,5,300,14,
      L=3
      FOR i=1 TO 10
      x=LEN(List(i))
      w=a*x+b
      CONTROL ADD LABEL,hDlg,-1,"Computed width is: "+STR$(w),0,5+i*16+2,80,14,
      CONTROL ADD COMBOBOX,hDlg,200+i,List(),80,5+i*16,w,11*10,%CBS_DROPDOWNLIST+%WS_TABSTOP
      COMBOBOX SELECT hDlg,200+i,i
      NEXT i
      DIALOG SHOW MODAL hDlg
      END FUNCTION

      Comment


      • #4

        Joe --

        > Knowing Microsoft's meaning of "average character width"
        > would help improve the display

        I'm not so sure that it would. After all, you don't know which characters are going to be displayed, right? Using Arial, which resembles the system font, "W" is about 3.5 times wider than "I" so IWI will not be as wide as WIW, even though they are both 3 characters long. Knowing the meaning of "average" wouldn't help much. And unless you're willing to do a statistical analysis of the text that you're displaying (for character frequency), probably the best you'll be able to do is a rough guess. Welcome to Windows. {G}

        The following text may or may not display the same on all browsers...

        WWWWWWWWWW = 10 W's
        IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII = 35 I's

        -- Eric



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

        "Not my circus, not my monkeys."

        Comment


        • #5
          If you need to know the exact length of text based on a font you can use the GetTextExtent*() API calls.

          That's how the URL control I posted determines when to change the mouse cursor to a hand.

          --Dave


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

          Home of the BASIC Gurus
          www.basicguru.com

          Comment


          • #6
            Thanks, Dave. I guess the SIZE structure will contain pixel lengths.
            I'll need to convert to dialog units, but I'm guessing that info is
            available in TextMetrics. I'll play around with it to see if I can
            find an algorithm to specify the box size in dialog units. In my case
            I'm looking for a way to make the box size independent of language -
            French, English, etc. An approximation might suffice, but I'll play with
            the code to see if a better solution is possible.

            Comment


            • #7
              Since you are using DDT, why not use the DIALOG PIXELS...TO UNITS statement to convert the "logical point" size returned by GetTextExtentPoint32(), and then adjust the dialog size to fit the text using the other DDT statements.

              Coordinate systems can be confusing.... the most common types encountered include Device Points (pixels), Logical Points, and Dialog Units (not to forget Twips, etc!) Once you get your API books, you'll discover how to translate between them, taking into account the current mapping mode, origins, etc... Correctly using the GDI can be very complex.

              In particular, the relationship between Dialog Units and Device Points (or Logical Point) is dependent on the system font... WIN32.HLP seems to suggest that there is a "fixed" relationship between the two, but in reality, the size ratio will vary depending on the system font and the size of the system font. This is important, because if you hard-code your calculations to convert between coordinate systems, you'll find your code does not run very well on different computers with different screen resolutions, etc.

              In summary, Petzold and Rector/Newcomer will show you the light!



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

              Comment


              • #8
                I haven't tried it, but it seems like the GetTextExtent* API functions would be difficult to use "cleanly" with DDT. They all require a Device Context as a parameter, which implies that the target window already exists, and (if I understand what he's doing) Joe wants to create a window that is just large enough to display a certain string of text. Since DDT automatically creates dialogs with the WS_VISIBLE style, you would see the dialog appear and then change size after the calculations had been done. I suppose you could create the dialog "off the screen" (i.e. located to the right of the right edge of the screen), then change the size, then re-locate the dialog so that becomes visible to the user. Or, if we are talking about a main window, it could be created as minimized, and a ShowWindow %RESTORE operation could be performed after it had been sized.

                Or, for a flashier effect, you could create the dialog as a very small window, do the calculations, and then use DIALOG SET SIZE in a loop to gradually make it longer, until all of the text was visible.

                -- Eric

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



                [This message has been edited by Eric Pearson (edited January 27, 2000).]
                "Not my circus, not my monkeys."

                Comment


                • #9
                  For dialogs with variable number of lines I set zero sizes in Dialog New.
                  Then recalculate units to pixel, add size of borders & caption and execute SetWindowPos. Short sample
                  Code:
                  #Compile Exe
                  #Register None
                  #Include "Win32Api.Inc"
                  Function PbMain()
                    Dialog New 0 ,"Sample", 0, 0, 0, 0, %WS_SYSMENU To hDlg&
                    nline& = 15
                    For i& = 1 To nline&
                       Control Add Label, hDlg&, 100 + i&, "Line" + Str$(i&), 10, i& * 12 - 6, 80, 10
                    Next
                    Dialog Units hDlg&, 100, (nline& + 1) * 12 To Pixels xx&, yy&
                    yy& = yy& + 2 * GetSystemMetrics(%SM_CYBorder) +  GetSystemMetrics(%SM_CYCaption)
                    xx& = xx& +  2 * GetSystemMetrics(%SM_CXBorder)
                    SetWindowPos hDlg&, 0, (GetSystemMetrics(%SM_CXSCREEN) - xx&) / 2, _
                       (GetSystemMetrics(%SM_CYSCREEN) - yy&) / 2, xx&, yy&, 0
                    Dialog Show Modal hDlg&
                  End Function
                  [This message has been edited by Semen Matusovski (edited January 27, 2000).]

                  Comment


                  • #10
                    Eric, unless I'm missing something obvious (and I've not tried this with DDT), I would think that it should be possible to obtain a DC to the Desktop and use that DC to perform the dialog unit conversion. If I have time, I'll try this and post my results.


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

                    Comment


                    • #11
                      Lance --

                      Yes, I guess that as long as you're dealing with the system font, that should work. Good idea. I was thinking too generically... I was trying to figure out how this task could be accomplished with any given font, and I (incorrectly) assumed that you'd have to use the actual target window.

                      -- Eric

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

                      "Not my circus, not my monkeys."

                      Comment


                      • #12
                        When you use DIALOG NEW, the dialog is created but not shown. Therefore, before you call DIALOG SHOW, you can use the handle to get a device context. And in your WM_INIT handler you can resize the dialog to any size you want.

                        --Dave


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

                        Home of the BASIC Gurus
                        www.basicguru.com

                        Comment


                        • #13
                          Dave --

                          Doh! Of course. I was really over-complicating things.

                          -- Eric


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

                          "Not my circus, not my monkeys."

                          Comment

                          Working...
                          X