What is a Dialog Unit

[Joe Speroni]

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

[Eric Pearson]

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

[Joe Speroni]

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

[Eric Pearson]

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>

[Dave Navarro]

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>

[Joe Speroni]

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.

[Lance Edmonds]

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>

[Eric Pearson]

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

[Semen Matusovski]

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

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

[Lance Edmonds]

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>

[Eric Pearson]

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]s[email protected]</A>

[Dave Navarro]

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>

[Eric Pearson]

Dave --

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

-- Eric


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