Announcement

**Aldo Cavini** · 26 Mar 2001, 05:01 AM

Egbert,

I don't understand how EXACT setup you need for your dialogs. Sometimes I write code that must be translated into other languages... strings are not the same length.

What I like in Dialogs is I have not to consider the font size: it's enough to know 4 horizontal units match the average width of one character (see GetDialogBaseUnits). You must consider also the borders, frames...

I think it is better to have items a little bit larger than a little bit smaller.

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

[This message has been edited by Aldo Cavini (edited March 26, 2001).]

**Borje Hagsten** · 26 Mar 2001, 05:36 AM

For simple dialogs, no problem. As soon as one start mixing CONTROL ADD
and CreateWindow, plus adding lists and buttons with text, big problems.

Only way, as I see it, is trial-and-error method, where you set your
computer to use big/small fonts and add code to grab sizes/locations
and resize-relocate according to results. I have just added something
like the following to the beta of Poffs2, to enable resizing, etc, in
main dialog's WM_SIZE event. While it doesn't cover all aspects, like
extreme user-defined settings, it enables covering the two most common
ones, big or small fonts.

Code:

CASE %WM_SIZE
  hdc = GetDC (hDlg)
  IF GetDeviceCaps(hDC, %LOGPIXELSY) = 96 THEN
     'small fonts, use CONTROL GET/SET SIZE or LOC one way
  ELSE
     'big or user defined fonts - usually even bigger than big..
     'use CONTROL GET/SET SIZE or LOC other way
  END IF
  CALL ReleaseDC hDlg, hdc)

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

**Michael Mattias** · 26 Mar 2001, 06:59 AM

... While it doesn't cover all aspects, like extreme user-defined settings...

In my experience, as soon as you give a user ANY setting or option, "extreme" becomes the norm.

Some kind of cosmic force or something....

MCM

**Lance Edmonds** · 27 Mar 2001, 10:15 PM

In general, if your dialogs use the system font, you won't have any problems, since that font is used to determine the dialog size at runtime by the Windows dialog engine.

If you have to use other fonts, you'll need to dynamically resize your controls accordingly. This is no easy task, but it is not impossible.

The concept of create dialog-based apps is to create dialogs that look the same as other windows apps. Using non-standard fonts is considered "poor practice" since you are deviating from GUI design fundamentals... YMMV of course, and you are obviously free to choose your own route.

Similarly, creating User Interfaces with "skins" is also considered a no-no by the Windows programming purists. Again, YMMV!!!

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

**Egbert Zijlema** · 27 Mar 2001, 10:59 PM

Lance,

I don't use fonts when creating dialogs. In other words, only the system default font is involved. As far as text is a concern, I'm using a GetTextExtent function now, as follows:
1. create an invisible dialog with zero-measurements.
2. pass a piece of text (actually: the largest string to use in the dialog or in a control) thru the GetTextExtent function, in order to retrieve values for cx and cy.
3. close the dialog (DIALOG END hDlg)
4. convert cx and cy from pixels to units
5. finally create the real thing

It works acceptable, although not perfect. In most cases labels and/or text boxes ar far too wide for the text. But better too wide than too narrow.
The cy-parameter, by the way, returns 10 du's for text height. I thought it ought to be 9 and I see Petzold even using 8 when creating radio buttons. What is the correct value?

BTW: Later today I'll replace my message box functions in the source code forum with a module using this 'new' technique.

So far about text. But what when bitmaps are involved? I have a dialog that shows a bitmap. The text labels available are not fit to retrieve cx and cy measurements, because they only use the rigth 'half' of the dialog. How can you be sure about the correct measurements?
Sometimes I have the impression that creating dialogs is a just matter of throwing dice instead of 'math and science'.

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

**Lance Edmonds** · 28 Mar 2001, 02:03 AM

The "standard" button control (push, radio, etc) height is usually 14 dialog units, so there should be plenty of room for the system font.

I gather you mean GetTextExtentPoint32() rather than GetTextExtent() ? I assume you are getting the DC to the dialog before this?

I'm afraid I don't understand your comments about bitmaps and using 1/2 of the dialog width. When dealing with bitmaps, you either have the choice of resizing the dialog to fit the bitmap, or StretchBlt'ing the bitmap to fit the dialog. The latter is preferable, since you can determine the dialog size based on the text, rather than the bitmap dimensions.

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

**Egbert Zijlema** · 28 Mar 2001, 02:22 AM

Lance,

Indeed: GetTextExtentPoint32(). I did'nt use the official name, but wrote about 'a' GetTextExtent function.

Now about the dialog with the bitmap (hope I can make myself clear enough):
The dialog is divided into 2 parts, not really on a 50:50 base. The left 'half' of the dialog is a picture. So, when I retrieve the cx-value for the text in the right part I only know how large or wide this 'half' should be.
But how does a programmer know in advance what the correct measurements for the bitmap-part of the dialog should be?

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited March 28, 2001).]

**Lance Edmonds** · 28 Mar 2001, 02:44 AM

Well, if you know how large the text 'side' has to be, and you want to use 50% of the width for the text, you know you are going to be using approx. the same width for the bitmap. If you use StretchBlt() to display the bitmap, where is the problem? (aspect ratios and stretching issues aside).

What I mean is this: if you really must use the absolute size of the bitmap, you are going to have problems (since a 640x460 bitmap is very small when BltBit()'ed to a 1280 pixel display, compared to an 800 pixel display.

I still suggest that you have to choose whether to base the size on the text OR the bitmap, but probably not both. Alternatively, supply different bitmaps for each resolution if the StretchBlt() method is not appropriate for you.

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

**Chris Boss** · 28 Mar 2001, 04:21 AM

Egbert;

In DDT, the default font used is the MS Sans Serif 8 pt and not the System font.
Windows created using CreateWindowEx will use the System Font by default.
When the system is set to Small Fonts, the character size for DDT
Dialogs is 6 x 13 pixels !

(note: I have done extensive testing of this for my Visual Designers)

A Dialog Unit is :

Horizontal - 1/4 of the Character Size of Dialogs Font
Vertical - 1/8 of the Character Size of Dialogs Font

The problem with GetTextExtentPoint32 is that you must make sure
the DC used for the calculation is the DC for the actual Dialog and
that the mapping mode is set correctly so it returns Dialog Units
and not Pixels (or something else).

When you look at the Petzoid code, likely he is working with SDK
style Windows (using CreateWindowEx) and by default the mapping mode
for such Windows is MMTEXT which means pixels.

You may want to calculate the width for your text using Pixels and
then use the appropriate DDT commands to convert Pixels to Dialog
Units. This means you can use the Desktops DC to calculate the text
size for a string using the MS Sans Serif 8 pt font (select this font
into the desktops DC) and return pixels and then create your DDT
Dialogs to a default size, but before you execute the Dialog Show command
simply resize the Dialog and its controls, by using the Pixels to Dialog Units
conversion available to DDT.

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

[This message has been edited by Chris Boss (edited March 28, 2001).]

**Egbert Zijlema** · 28 Mar 2001, 05:15 AM

Folks,

I replaced my message box functions in the source code forum with a newer one.
I'm using GetTextExtentPoint32 now to get width and height. Also, a MsgDlg can process 3 lines for the message now.
And! I've added 2 new message styles, which Windows does not supply.

Aldo,
In the BtnText function I almost finished the 'Italian' buttons. After you add 4 or 5 correct names, the functions should work correctly in Italy and the Italian part of Switzerland.

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[This message has been edited by Egbert Zijlema (edited March 28, 2001).]

**Dominic Mitchell** · 28 Mar 2001, 09:51 PM

The problem with GetTextExtentPoint32 is that you must make sure
the DC used for the calculation is the DC for the actual Dialog and
that the mapping mode is set correctly so it returns Dialog Units...

This should not be possible since Windows does not use dialog units.
The functions that work on the dialog scripts(templates) converts
dialog units to pixels and DS_XXX to WS_XXX before the real api goes
to work.

------------------
Dominic Mitchell

Announcement

dialog measurements

dialog measurements

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment