Announcement

**E B Knoppert** · 8 Feb 2000, 12:24 PM

Usually, a selfcreated window has the styles;
%CS_HREDRAW OR %CS_VREDRAW in it's class.
This will use something simmilar to InvalidateRect hWnd, ByVal 0&, -1

Where -1 stands for erase background (and wm_paint)
Or 0 for painting only.

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

**E B Knoppert** · 8 Feb 2000, 12:26 PM

Don't forget Postmessage, this is a handy windows feature to do things after the current message.
Like wm_ctlstatic (~) color msg.. Post a message to paint it

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

**Semen Matusovski** · 8 Feb 2000, 12:36 PM

Joe --
insert following lines in %WM_SIZE

Dim tRect As Rect
GetClientRect CbHndl, tRect
MsgBox Str$(tRect.nRight - tRect.nLeft) + Str$(tRect.nBottom - tRect.nTop), , "Client area, pixels"
MsgBox Str$(LoWrd(CbLparam)) + Str$(HiWrd(CbLparam)),, "WM_SIZE"
GetWindowRect CbHndl, tRect
MsgBox Str$(tRect.nRight - tRect.nLeft) + Str$(tRect.nBottom - tRect.nTop), , "Window size, pixels"
Dialog Pixels CbHndl, (tRect.nRight - tRect.nLeft), (tRect.nBottom - tRect.nTop) To Units xx&, yy&
MsgBox Str$(xx&) + Str$(yy&),, "Window size, units"

Hope, it will be an answer for you

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

**Joe Speroni** · 8 Feb 2000, 12:59 PM

Thanks Semen. Now I get it. The sizes from LParam are in
pixels and they have to be converted to dialog units.
I assume that the values in LParam are really the same as in
in the tRect structure (computed from nLeft, nRight, nTop and
nBottom)!?

I didn't really follow E B Knoppert's comments, but I'll keep
reading WinHLP32 and Petzold in the areas he described.
Intuitivly it seems to me that I can't just clear the pixels
in the window without removing the buttons one-by-one since
mouse events might still be active even if the button is not
visible. But how to do this?

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

**Semen Matusovski** · 8 Feb 2000, 02:23 PM

Joe --
There are no problems to convert PIXEL to UNITS, UNITS TO PIXELS after DIALOG NEW.
UNITS are useful, because they are "resolution-independent".
It's necessary only to do one. In Control Add are coordinates for client's area. In DIALOG NEW - window's area.
After DIALOG NEW better to calculate difference beetween client and window area - in units it's not "resolution-independent" -and to correct sizes of dialog.
Perhaps, you will not agree with me, but I think that resizing is very difficult problem. It's recalculations positions of all elements, changing fonts and so on. Stupid and difficult work.

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

**Joe Speroni** · 8 Feb 2000, 07:04 PM

Semen,
It is difficult to resize, but so far I have all of my text
and button positions computed relative to the width of the
dialog window. Once I know the new xx& and yy& I can easily
repaint a screen in my program. All text is in a string
array read from a file, and the width of buttons
is computed based on the length of the text in each record.
(the average of 4 dialog units per character length is a small
problem so I'm using 4.3 to have some extra room).

I did this so that the screens can "relatively eaily" be
translated into other languages and I don't have to resize
anything in the program. That's the theory at least. It has
worked with DOS programs, and that part seems a little easier
in Windows. But you have to know the API, which I'm just
starting to get a handle on.

Now I have to figure out how to erase the dialog window to be
able to repaint it. Guess I'll start experimenting with test
programs.

Again thnaks for your help.

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

**Joe Speroni** · 8 Feb 2000, 11:36 PM

Semen, I discovered that from within a CB function I can remove
all controls from the screen using the command

CONTROL KILL hDlg&, %ID

and then CONTROL ADD to put new controls on the same screen.
This solves my problem. I can "simulate" the DIALOG NEW command
for the new dislog, using the previous dialog screen. Minor
problem to solve is the text to the title bar. But that should
be easy.

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

**Semen Matusovski** · 8 Feb 2000, 11:45 PM

Joe --
I modified one training code to demonsrate textbox/button resizing.
With labels - if you do not change font and so on, better to change location only.

Code:

#Compile Exe
#Register None

#Include "Win32Api.Inc"
%ID_TextBox =  101
%ID_Button = 201

CallBack Function hDlg_CB()
   Dim BrushLtBr As Static Long, BrushWhite As Static Long, BrushBlue As Static Long
   Select Case CbMsg
      Case %WM_INITDIALOG
         Local Lb As LOGBRUSH
         Lb.lbStyle = %BS_SOLID
         Lb.lbColor = &H80C0FF: BrushLtBr = CreateBrushIndirect(Lb)
         Function = %TRUE
      Case %WM_DESTROY
         DeleteObject BrushLtBr
      Case %WM_CTLCOLORDLG ' Return the handle of the dialog background brush.
         Function = BrushLtBr
      Case %WM_SIZE
         x& = LoWrd(CbLparam): y& = HiWrd(CbLparam) ' pixels
         Dialog Pixels CbHndl, x&, y& To Units xx&, yy&
         ' Relation sizes Left   : 0.1 * Width of client area
         ' for TextBox    Top    : 0.05 * Height * of Client area
         '                Width  : 0.8  * Width of client area
         '                Height : 0.2 * Height * of Client area
         Control Set Loc  CbHndl, %Id_TextBox, 0.1 * xx&, 0.05 * yy&
         Control Set Size CbHndl, %Id_TextBox, 0.8 * xx&, 0.4 * yy&
         Control Set Text CbHndl, %Id_TextBox, "Width = " + Str$(x&) + " pixels " + $CRLF + _
                                               "Height = " + Str$(y&) + " pixels"
         Control Set Loc CbHndl, %Id_Button, 0.1 * xx&, 0.65 * yy&
         Control Set Size CbHndl, %Id_Button, 0.8 * xx&, 0.2 * yy&
   End Select
End Function

Function PbMain ()
  Dialog New 0 ,"Resizing",0,0, 105, 90, %DS_CENTER Or %WS_OVERLAPPEDWINDOW To hDlg&
  Control Add TextBox, hDlg&, %ID_TextBox, "", 0, 0, 0, 0, %ES_WANTRETURN Or %ES_MULTILINE Or %ES_AUTOVSCROLL, %WS_EX_CLIENTEDGE
  Control Add Button, hDlg&, %ID_Button, "This is a button", 0, 0, 0, 0
  Dialog Show Modal hDlg&, Call hDlg_CB
End Function

PS. Joe, I can't understand, why you want to kill elements. If you have different quantity of them - it's clear, but it seems to me that you want to resize only.

[This message has been edited by Semen Matusovski (edited February 09, 2000).]

**Joe Speroni** · 9 Feb 2000, 12:11 AM

Semen, WOW that is harasho. Ochen spaciba.

The KILL solution had two reasons. One to resize, and the other
to handle chaining of menus - up to four deep. Right now I open
a new dialog each time, which clutters the screen.

You know it is one thing to read the explantion of a command,
and another to really understand what it means. Coming from the
DOS environment I have little intuition of Windows programming.
Thanks so much for your help!!!

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

**Lance Edmonds** · 9 Feb 2000, 03:27 AM

If you want to make the job of resizing your dialog MUCH easier, then you might want to take a look at my commercial RESIZE32 custom control. It can resize DDT dialogs as well as standard dialogs, and windows created with CreateWindow(), etc.

It provides ways to specifying how controls should be resized, such as proportional to the client dimensions (elastic), or "anchored" to one or more edges of the parent window. You can even mix the styles.

It employs auto-subclassing, so you only need to call the engine once for each dialog to get elastic resizing going for all child controls, or you can add a PBRESIZE32 custom control to the dialog/window to get the engine running automatically. It handles child dialogs transparently, so you can even use it with tab-controls!

Several examples are included with the demo, and the actual DLL is a compact 36K bytes!

Email me privately, and I'll send you a free demo. The demo is a fully working version of the engine, but with a "nag" screen.

mailto:[email protected][email protected]</A>

Regards,
Lance.

Announcement

Resizing Dialog Windows

Resizing Dialog Windows

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment