PB 7.0 Wish List ! ! !

[Chris Boss]

There is one thing I would like to see in PB DLL 7.0 :


(1) The coordinates (and width and height) for "all" DDT commands
(Dialogs/controls) should be Single precision, rather than longs.



[This message has been edited by Chris Boss (edited July 18, 2000).]

[Scott Hauser]

Chris,

I would like to see Items (2), (3) and (4) added, but am somewhat confused by item
(1).

Perhaps I am being thickheaded, but if 1 dialog unit is the smallest
unit that a resource compiler can process, how would item (1) improve
the final screen appearance? It would seem that plus or minus 1 dialog unit is the
is the finest 'nudge' a control could receive.

Scott

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

[Chris Boss]

I have removed many of my comments from this thread because
they may be construed as a criticism of PowerBasics DDT.

I apologize if they have and the only thing I can say to show
how I "truly" feel about the PowerBasic compiler is:

The PB Compiler is the best compiler I have ever used
and every programmer should buy a copy

I will continue to "strongly" support PowerBasic as an addon
developer and I "look forward" to future versions of PB.


[This message has been edited by Chris Boss (edited July 18, 2000).]

[Scott Hauser]

Hi Chris,

I see your point. DDT would be off by .25 pixel/DialogUnit_X. Within 3-4 dialog units sharp
eyes could begin to detect it. I would vote for using the industry standard dialog unit
calculations in the next version of DDT.

Because you know what the actual differences are, you could create a mapping factor for
your EZGUI dialog editor for the short term. This technique would work provided the
MS vs DDT difference in calculation is global.

We do not know with certainty which of our wishes will be adopted in the version of PB/DLL
and it would be a shame to limit your package until that time.

Scott
------------------


[This message has been edited by Scott Hauser (edited July 17, 2000).]

[Chris Boss]

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

[This message has been edited by Chris Boss (edited July 18, 2000).]

[Chris Boss]

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

[This message has been edited by Chris Boss (edited July 18, 2000).]

[Chris Boss]

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


[This message has been edited by Chris Boss (edited July 18, 2000).]

[B Hall]

Here is a somewhat related issue to putting new features into a
programming language and that is:

What is the Windows programming method of printing to the screen?

Is it use of a full size list box? Or is it API calls?

If its a list box, then can the list box have two-color rows or
multi-colored areas?

So, while I need those answers to be sure, the point is shouldn't
we take programming beyond Windows programming method. Say a
combination of DOS-style programming and Windows-style programming.



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

[Scott Hauser]

Hi Chris,

Due to the facts you pointed out, I would bet the farm on a math rounding differences somewhere.

IF:

"X Dialog Units is 1/4 of a character width
Y Dialog Units is 1/8 of a character height"

"If your PC is using the "Small Fonts" setting:"

"DDT will calculate a character size as 6 x 13 pixels
Windows Dialog engine will calculate the size as 7 x 13" pixels

AND:

"Using DDT, then a X Dialog Unit is 6/4 or 1.5 pixels
and a Y Dialog Unit is 13/8 or 1.625 pixels"

The smallest drawing we could expect to produce in terms of dialog units would be:
1 dialog unit = 1 or 2 pixels X, and 2 Pixels Y, depending how the programmer elected
to treat the Real numbers. Or perhaps successive small calculations, when rounded,
added up to a visible difference.

I was sorry to see you shelve the DDT generator, I was looking forward to it. But as
I said earlier "We do not know with certainty which of our wishes will be adopted in the version..."
and that applies to the EZGUI dialog designer as well.

Scott


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

[Semen Matusovski]

Chris --
I think that in future release DDT will allow custom font.
From one side, DDT is very comfortable. From another, it's engine with unknown interiours.

Because you create Visual Designer and generate code, you can create own "DDT-language".
For example, Dialog_New ..., Control_Add ... , where Dialog_New and Control_Add are subroutines, which you include in generated code.
(instead of optional parameters it will be necessary to use special values).


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

[Chris Boss]

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


[This message has been edited by Chris Boss (edited July 18, 2000).]

[Semen Matusovski]

Chris --
1) I think, that DDT converts units to pixels by very simple way.
Correct me, if I'm wrong.

   #Compile Exe
   #Register None
   #Dim All
   #Include "win32api.inc"
   %x1 = 65
   %x2 = 517
   %y1 = 160
   %y2 = 227
   
   Function PbMain
     Dim hDlg As Long, rc1 As Rect, rc2 As Rect
     Dialog New 0, "Select Test", %x1, %y1, %x2 - %x1, %y2-%y1, %WS_SYSMENU To hDlg
     rc1.nLeft= %x1: rc1.nRight = %x2
     rc1.nTop = %y1: rc1.nBottom = %y2
     MapDialogRect hDlg, rc1
     GetWindowRect hDlg, rc2
     MsgBox "MDR :" + Str$(rc1.nRight - rc1.nLeft) + Str$(rc1.nBottom - rc1.nTop), , _
            "GWR :" + Str$(rc1.nRight-rc1.nLeft) + Str$(rc2.nBottom-rc2.nTop)

   End Function

2) It looks, that you understood my idea incorrect.
I suggest to refuse from DDT support at all and instead of this to create own analog.
In this case you (and your customers) will be fully independent.

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

[Matthew Berg]

What is the Windows programming method of printing to the screen?

Is it use of a full size list box? Or is it API calls?

If its a list box, then can the list box have two-color rows or
multi-colored areas?

What do you mean by "printing to the screen"? Are you talking about "printing" text in a console window, or outputting text in a device context, or... ?

Yes you could have a list box in which any given row/item could have multi-colour text. This would be an owner-draw list box, and you would have to draw the text for each item yourself.

[Dominic Mitchell]

Chris,
The method use by Microsoft is a bit odd. Microsoft recommends that
when calculating average character widths that you round up the result, hence the formula.
This is the same technique used by the MS dialog editor. Now, if you are going to generate
a form in dialog units then you should give the user the option of working in dialog units
in the visual designer. This would get rid off alignment problems when the controls are
generated. As for the method used by DDT to calculate dialog units, there are actually two
versions of that formula -
GetTextExtentPoint32 hDC,"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", 52, tsize

1. Round up the average character width
tsize.cx = (tsize.cx / 26 + 1) / 2

2. tsize.cx = (tsize.cx / 26)
' Round up the average character width
tsize.cx = (tsize.cx + 1) / 2

For the DEFAULT_GUI_FONT the produce the following(width * height)
1. 13 * 7 pixels
2. 13 * 6 pixels

Well, tsize is a udt of two LONGs so the second method is rounding up a value that has been
rounded or truncated. The second method is the one used by the MS dialog editor.
There are actually two MSDN knowledge base articles on this subject. One gives method 1 and
the other gives method 2. Method 2 the one actually used by Windows is in my opinion, funky math.



[This message has been edited by Dominic Mitchell (edited July 18, 2000).]

[B Hall]

Response to response:

In native Windows GUI programming, what is the Windows programming
method of outputting the contents of a file or outputting the
contents of an array...to the screen (to the active Window)?

A Window size list box? The list box does not have to be white?

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

[Lance Edmonds]

Just to clarify one point... DDT does not do any "Dialog Unit" calculations or conversions when creating DDT dialogs. DDT uses the dialog engine to do all of the translations in a similar manner to loading a dialog from a resource file.



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

[Chris Boss]

I apologize if I implied DDT "calculated" the dialog unit size.

I guess I may be in error on that one.

The Windows Dialog Engine "does" though calculate a Dialog Units
size and the MS docs indicate (see MS web site) the suggested
method of doing this yourself (if you need to).




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

[Semen Matusovski]

Originally posted by Lance Edmonds:
DDT does not do any "Dialog Unit" calculations

I have two stupid questions (probably, I don't know CreateDialog)
1) %WS_CAPTION, when sizes in Dialog New are client.
2) Pixels To Units




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

[Scott Hauser]

Hi,

I played with this a little, and if there is any error in calculation, it must be in
one of the MicroSoft api functions. The result was always 8 X 16 on my system. This
implies a 2 pixel X, 2 Pixel Y Dialog Unit on my system. I also tried significant changes
to the denominator to evaluate its influence on the result. The code that follows is a
is a modified version of code Chris posted in a prior thread.

Scott

#COMPILE EXE
#INCLUDE "win32api.inc"
GLOBAL hFont AS LONG

FUNCTION PBMAIN() AS LONG
    LOCAL hOldFont AS LONG, hDC AS LONG
    LOCAL TM AS TEXTMETRIC, LT AS ASCIIZ * 80, SZ AS SIZEL

    hDC = GetDC(%HWND_DESKTOP)
    hOldFont=SelectObject(hDC, hFont)  ' ie. font handle for MS Sans Serif 8
    GetTextMetrics hDC, TM

    LT="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"+CHR$(0)

    GetTextExtentPoint32 hDC, LT, 52, SZ
    MSGBOX "SZ.cx = "  & STR$(SZ.cx),,"     SZ.cx     "

    BaseX&=(SZ.cx/26+1)/2 :MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/26+1)/2    "   'reports 9
    BaseX&=(SZ.cx/52): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/52)    "     'reports 8

    ' Lets test changes to denominator
    BaseX&=(SZ.cx/50): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/50)    "     'reports 9
    BaseX&=(SZ.cx/51): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/51)    "     'reports 8
    BaseX&=(SZ.cx/53): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/53)    "     'reports 8
    BaseX&=(SZ.cx/54): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/54)    "     'reports 8
    BaseX&=(SZ.cx/55): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/55)    "     'reports 8
    BaseX&=(SZ.cx/56): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/56)    "     'reports 8
    BaseX&=(SZ.cx/57): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/57)    "     'reports 8
    BaseX&=(SZ.cx/58): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/58)    "     'reports 7
    BaseX&=(SZ.cx/59): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/59)    "     'reports 7
    BaseX&=(SZ.cx/60): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/60)    "     'reports 7
    BaseX&=(SZ.cx/61): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/61)    "     'reports 7
    BaseX&=(SZ.cx/62): MSGBOX STR$(BaseX&),,"     BaseX&=(SZ.cx/62)    "     'reports 7

    BaseY&=TM.tmHeight    'reports 16

    'testing Dominic's theory
    '1. ROUND UP the average character width
    'SZ.cx = (SZ.cx / 26 + 1) / 2

    '2. SZ.cx = (SZ.cx / 26)
    SZ.cx = (SZ.cx / 26): MSGBOX "SZ.cx / 26 = " & STR$(SZ.cx) ,, "SZ.cx = (SZ.cx / 26)" 'reports 16


    ' Round up the average character width
    SZ.cx = (SZ.cx + 1) / 2: MSGBOX "(SZ.cx + 1) / 2 = " & STR$(SZ.cx) ,, "SZ.cx = (SZ.cx + 1) / 2" 'reports 8

END FUNCTION

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

[Chris Boss]

Scott;

The 8 x 16 character size is for the System Font which
Windows defaults to for windows created using CreateWindowEx.

Your code doesn't define hFont (using CreateFont), so its value
will be zero (0) and I think this is the handle for the default
System font or either the SelectObject is failing since hFont=0 and the
current font is left (System). (there are 5 default fonts predefined
by windows already, Systme, System Fixed, Ansi, Ansi fixed and OEM)

Your code is simply not correctly selecting the MS, Sans Serif font.

The Windows Dialog engine uses whatever font has been defined as the
main font for the Dialog to calculate Dialog units. The MS Dialog
editor defaults to the MS Sans Serif, 8 point font which has a
character size of 7 x 13.

Visual basic defaults to the MS Sans Serif 8 point font, so it is
the "prefered" font for creating Dialogs.

If you would like some "detailed" discussions of Dialog Units, I
suggest you check out the Microsoft web site (the one for developers)
and do a search for the words "Dialog Unit". It is enlightening, to
say the least.

Thats about all I can comment on at this time.

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




[This message has been edited by Chris Boss (edited July 19, 2000).]