Announcement

**Semen Matusovski** · 9 Jun 2000, 01:12 AM

Peter --
process %WM_SIZING message (don't mix with %WM_SIZE)

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

**Peter Stephensen** · 9 Jun 2000, 01:22 AM

Semen --

WM_SIZING is send all the time during the drag-operation. I need to know when the drag-operation ends. And this is when the left mouse button is released.

Regards
Peter

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

**Semen Matusovski** · 9 Jun 2000, 01:46 AM

Peter --
I don't know, what you want to do.
WM_SIZING really occurs permanently.
WM_SIZE - one time after last WM_SIZING and indicates that left button is released.

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

**E B Knoppert** · 9 Jun 2000, 02:12 AM

Isn't this a hittest?
%HT_...

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

**Peter Stephensen** · 9 Jun 2000, 02:19 AM

Semen --

On my NT it is not as you say: both WM_SIZE and WM_SIZING occurs permanently. I think there may be a difference between NT and win95, but i am not sure.

I'm trying to make a docking window. Let's say i have two winndows: A and B. When i resize window A i would like window B to resize accordingly. To avoid flickering, i dont want this to happen continously. I want window B to wait for window A to finish its resizing.

Regards
Peter

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

**Peter Stephensen** · 9 Jun 2000, 02:35 AM

EB --

I have tried to respond to WM_NCLBUTTONUP. It dont work.
In my last post to Semen you can see what i am trying to do.

I have added this test-code to the callback function of window A:

Code:

case %WM_NCLBUTTONUP 
    msgbox "test"

When i resize window A nothing happens. On the other hand, if i doubleclick on the border of window A the message box opens. Strange!

Regards
Peter

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

**Scott Turchin** · 9 Jun 2000, 02:48 AM

If you want to resize from the control that is being used (Ie the corner of the status bar) then you will need to use the callback for the Status bar to do that, OR put the Statusbar's ID in the maincallback (Try under WM_COMMAND)

Case %IDSTATUSBAR
select case cbwparam
case WM_LUTTONUP
end select

This syntax may be inccorect, but the point should be there Etc...

Here's my general template I use for callbacks

PS, using a little bit of ESP here (LOL), sometimes i have to do this when I use a specific status bar etc: (Or using DDT)

Code:

CallBack Function HtmlProc() As Long

    Select Case CbMsg
    Case %WM_ACTIVATE
    Case %WM_INITDIALOG
    Case %WM_SIZE
         Control Send hDlg,hStatus, %WM_SIZE, cbwParam, cblParam  

    Case %WM_COMMAND 'Insert most menu's etc here
        Select Case CBWParam
        End Select
    End Select

End Function


The mistake I have made in the past is putting the WM_SIZE under the WM_COMMAND, maybe not applicable to you, just adding my onion   [img]http://www.powerbasic.com/support/forums/smile.gif[/img]

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

[This message has been edited by Scott Turchin (edited June 09, 2000).]

**Semen Matusovski** · 9 Jun 2000, 03:09 AM

Peter --
Yes, I told about Win95.
This works fine under Win95.
Don't know about NT, I am too lazy to reboot.

Code:

   #Compile Exe
   #Dim All
   #Register None
   #Include "win32api.inc"

   CallBack Function DlgProc
      Static x As Long, y As Long
      Select Case CbMsg
         Case %WM_SIZING: x = 1: y = SetTimer(CbHndl, 1, 250, ByVal 0)
         Case %WM_TIMER: If x = 1 Then KillTimer CbHndl, y: x = 0: MsgBox "ok"
      End Select
   End Function

   Function PbMain
      Local hDlg As Long
      Dialog New %HWND_DESKTOP, "", , , 400, 200, %WS_CAPTION Or %WS_SYSMENU Or %WS_THICKFRAME To hDlg
      Dialog Show Modal hDlg Call DlgProc
   End Function

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

**Peter Stephensen** · 9 Jun 2000, 03:34 AM

Semen --

Nice hack. But there have to be a more regular way.

Regards
Peter

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

**Chris Boss** · 9 Jun 2000, 04:10 AM

Peter;

Once your window begins processing the Left Button Down (Drag Border) operation, Windows is in total control of what occurs until the Drag Border operation stops. Likely it "eats up" the Button Up message so your window procedure doesn't receive it.

Understanding "what" Windows does with certain messages (and if they even occur) can be at the core of some problems. Don't make assumptions about how Windows handles messages. A Button down message doesn't always mean there will be a button up message.

A trick I use when trying to understand what messages get fired and when is:

Put the BEEP command in any message you want to test, rather than a messagebox. Windows sometimes doesn't like Messageboxes being created during certain messages. Then listen for the computer to Beep so you know "when" a message is actually being fired (and even if it will occur).

Some "actions" in Windows (like Sizing a Window) work differently than we expect. Usually Sizing a Window (Drag a Border) or a similiar action causes Windows to "Capture" the mouse. Capturing the mouse will then "prevent" normal mouse events to occur. When the mouse is captured Windows acts like there is only one window in existance and ignores everything else. Coordinates outside the Window that captures the mouse are now legitimate, whereas before they weren't (meaning they belonged to another window).

Likely when the mouse button goes down on the border, the default window procedure that processes it, doesn't return until the mouse button goes up. This means there will likely be no mouse up message at all.

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

**Semen Matusovski** · 9 Jun 2000, 04:31 AM

I'm afraid that monitoring Left Button Up is not a good solution.
It's very easy to detect this event during resizing, using ordinary local mouse hook (I tested under Win95b).
But when to begin ? From the moment of first %WM_SIZING ? Not correct, because to this moment left button could be already released.

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

**Cecil Williams** · 9 Jun 2000, 05:10 AM

Peter,

When resizing a window i would like to detect when the left button is released (detecting when the drag operation is ended).
WM_LBUTTONUP is no good. Any ideas?

Ran your problem thru Spy++, the last message sent to the window was the WM_NCPAINT message THAT MEANT ANTHING when the left button was released. No other button messages were observed during this sequence. This was done with NT4.0.

Hope this helps!!!

Cheers,
Cecil

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

[This message has been edited by Cecil Williams (edited June 09, 2000).]

**Jules Marchildon** · 9 Jun 2000, 05:16 AM

Peter,

The sample I emailed to you should do want you want. In the main
window procedure, after it is resized, the WM_SIZE message is sent.
And you handle your sizing of child windows as follows:

Code:

...

   CASE %WM_SIZE
      SendMessage hStatus, wMsg, wParam, lParam
      SendMessage hToolTop, wMsg, wParam, lParam
      CALL SizeDockChild()
      CALL SizeClient()   

...
 
 
'-----------------------------------------------------------
'Resize Client window to snuggly fit the Frame window
'-----------------------------------------------------------
SUB SizeClient()
 
LOCAL cRect       AS RECT
LOCAL ToolHeight  AS LONG
LOCAL StatHeight  AS LONG
LOCAL DockHeight  AS LONG
LOCAL ChildHeight AS LONG
LOCAL ChildWidth  AS LONG
'---
'fill up RECT structure
'for ref'=>nLeft(x), nTop(y), nRight(cx), nBottom(cy)
'---
GetWindowRect hToolTop, cRect
ToolHeight = cRect.nBottom - cRect.nTop
GetWindowRect hStatus, cRect
StatHeight = cRect.nBottom - cRect.nTop
 
IF fDockFloat = 1 Then
   GetWindowRect hWndDockFloat, cRect
   DockHeight = cRect.nBottom - cRect.nTop
End If
 
If fDockChild = 1 Then
   GetWindowRect hWndDockChild, cRect
   ChildHeight = cRect.nBottom - cRect.nTop
   ChildWidth = cRect.nRight - cRect.nleft
End If
 
 
 
GetClientRect hWnd, cRect
MoveWindow hwndClient, _
           cRect.nLeft   + ChildWidth, _
           ToolHeight    + DockHeight, _
           cRect.nRight  - ChildWidth, _
           cRect.nBottom - (ToolHeight + StatHeight + DockHeight), _
           %TRUE
 
'**Resize to Client any Max'd child windows not docked
'I found that using the MoveWindow when a window is Maximized
'gives the window a border in its Maximized state.
 
If IsZoomed(hWndChild) = %TRUE Then
    GetClientRect hWndClient, cRect
    MoveWindow hWndChild, cRect.nLeft,cRect.nTop, _
                          cRect.nRight,cRect.nBottom,%TRUE
End IF
 
END SUB
 
'---
SUB SizeDockChild()
 
IF fDockChild = 1 THEN
    Local cRect as RECT
    LOCAL ToolHeight  AS LONG
    LOCAL StatHeight  AS LONG
    LOCAL DockHeight  AS LONG
 
    'get StatHeight,ToolHeight,DockHeight
    GetWindowRect hToolTop, cRect
    ToolHeight = cRect.nBottom - cRect.nTop
    GetWindowRect hStatus, cRect
    StatHeight = cRect.nBottom - cRect.nTop
 
    IF fDockFloat = 1 Then
        GetWindowRect hWndDockFloat, cRect
        DockHeight = cRect.nBottom - cRect.nTop
    End If
 
    GetClientRect hWnd, cRect
    SetWindowPos hWndDockChild,hWnd,cRect.nLeft, _
                 cRect.nTop+(ToolHeight + DockHeight),80,cRect.nBottom _
                 -(StatHeight + ToolHeight + DockHeight), _
                 %SWP_NOZORDER OR %SWP_DRAWFRAME
 
    UpdateWindow hWndDockChild
END IF
 
END SUB

If you want to detect when one of the child windows have been resized,
then simply trap the wm_size for that window and pass it on to wm_size
message back to the parent.

Regards, Jules

**Lance Edmonds** · 9 Jun 2000, 06:17 AM

One thing to note here guys - %WM_SIZE is the correct message to intercept for a resizing operation, but the behavior of this message varies from version to version of Windows!

Recent versions of Windows, and older versions that had the "PLUS" pack installed, added an "new" visual feature called "Show Window contents while dragging" (or something like that).

Normally, just one %WM_SIZE message being sent when the resize was finished (seeing just an outline of the window during the drag), but this feature causes a stream of %WM_SIZE messages to be sent *during* the resize drag so that the window can continuously resize itself while the resize drag occurs.

The most common complaint with this feature was the dramatic flicker that was experienced when an app window was resized.

If I remember, there is (or was) a way of disabling this effect with TweekUI or KernelTools... altering a Registry setting without a doubt.

Anyway, food for thought!

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

**Ian Cairns** · 9 Jun 2000, 09:16 AM

This annoying flicker could be disposed of if we could query the mouse driver directly, using interrupt &H33 as we did in DOS to ascertain the position of the mouse button.

How about it? Is it possible to write an ASM routine that queries the windows mouse driver? ie. IsLButtonDown(), IsMButtonDown() and IsRButtonDown(). Then you could do a:

Code:

CASE %WM_SIZE
  IF IsLButtonDown() = %FALSE THEN
... Now do the resizing of the child window/control.
  ELSE
... Resizing continues!
  END IF

Regards,

------------------
[email protected]

**Jules Marchildon** · 9 Jun 2000, 10:16 AM

Go to this link for TweakUI and many topics regarding Windows 98 Annoyances.

http://www.annoyances.org/win98/

You may find the answer there.

If you have control over your program and you are handling the
WM_SIZE message yourself, then can't you just eat up the string of
messages by NOT passing it on to the default window function ?

Or maybe a combo of WM_LMOUSEDOWN,WM_SIZING,WMLMOUSEUP Setcapture
and a flag could do the trick ?

Regards, Jules

Announcement

resizing window problem...

resizing window problem...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment