Pls Help with SetCapture()... - Programmer

This is a discussion on Pls Help with SetCapture()... - Programmer ; Hi, I'm trying to use the SetCapture() API and am having a few problems with it. It has worked fine for me in the past, so I'm not quite sure what the problem is and whether its in MFC or ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Pls Help with SetCapture()...

  1. Pls Help with SetCapture()...

    Hi, I'm trying to use the SetCapture() API and am having a few problems with
    it. It has worked fine for me in the past, so I'm not quite sure what the
    problem is and whether its in MFC or Win32.

    Here is the scenario:

    I'm trying to implement "full drag" MFC control bars. For the sake of
    argument a CToolBar. By "full drag" I mean Office 2003 style where the
    toolbar is moved around in real time and you can see it completely rather
    then the lame stock MFC "outline style drag". I've got this part all
    working.

    Here is the problem:

    I can drag the toolbars and they dock, float correctly. When a toolbar is
    docked, and I click on the gripper and drag it around, it floats and I can
    drag it all around the screen no problem and redock it to my hearts content.

    BUT... if the toolbar is FLOATING and I go to drag it by clicking on the
    caption, I can drag it around too, but I loose control of it if I move the
    mouse outside the main frame window?!?!?! What gives??? I no longer get
    WM_MOUSEMOVE messages. But if I started the drag from a docked position,
    this works perfectly fine.

    So the toolbar is floating, I click on the gripper to start a drag and the
    mouse cursor turns to a cross-hair. I drag it across and it docks where its
    supposed to, but once I move outside the frame, the cursor turns back an
    arrow, and the toolbar no longer moves if I move back into the frame, I
    suddenly regain control.

    I've seen some references on the net where SetCapture() will only capture
    messages for windows belonging to the current thread, but never saw a reason
    why or how to work around it.

    The mouse button IS down when I call SetCapture() as I'm calling it from
    WM_NCLBUTTONDOWN.

    I sort of worked around it by installing a Mouse Hook and a Low Level Mouse
    hook system wide and redirecting messages to my callback window. This worked
    fine (or so I thought) with only a minor performance hit, and I only left
    the hooks installed during a drag operation. Recently I noticed it doesn't
    seem to catch all the mouse movements (like if I am mousing over a DOS
    window or Media Player).

    I found another work around by installing a journal hook instead of the
    other two hooks, but that journal hook seems to cause a bigger performance
    hit then the other two combined.

    Seems like the most efficient would be to get the SetCapture() method
    working... but why is it only trapping messages when the mouse is over my
    process (or always when the drag is started from a docked position).



  2. Re: Pls Help with SetCapture()...

    Does this from MSDN explain it?

    "Only the foreground window can capture the mouse. When a background window
    attempts to do so, the window receives messages only for mouse events that
    occur when the cursor hot spot is within the visible portion of the window.
    Also, even if the foreground window has captured the mouse, the user can
    still click another window, bringing it to the foreground. "


    --

    Ken Wickes [MSFT]
    This posting is provided "AS IS" with no warranties, and confers no rights.


    "Nobody" wrote in message
    news:8Nm4e.72085$AN1.24738@fed1read03...
    > Hi, I'm trying to use the SetCapture() API and am having a few problems
    > with it. It has worked fine for me in the past, so I'm not quite sure what
    > the problem is and whether its in MFC or Win32.
    >
    > Here is the scenario:
    >
    > I'm trying to implement "full drag" MFC control bars. For the sake of
    > argument a CToolBar. By "full drag" I mean Office 2003 style where the
    > toolbar is moved around in real time and you can see it completely rather
    > then the lame stock MFC "outline style drag". I've got this part all
    > working.
    >
    > Here is the problem:
    >
    > I can drag the toolbars and they dock, float correctly. When a toolbar is
    > docked, and I click on the gripper and drag it around, it floats and I can
    > drag it all around the screen no problem and redock it to my hearts
    > content.
    >
    > BUT... if the toolbar is FLOATING and I go to drag it by clicking on the
    > caption, I can drag it around too, but I loose control of it if I move the
    > mouse outside the main frame window?!?!?! What gives??? I no longer get
    > WM_MOUSEMOVE messages. But if I started the drag from a docked position,
    > this works perfectly fine.
    >
    > So the toolbar is floating, I click on the gripper to start a drag and the
    > mouse cursor turns to a cross-hair. I drag it across and it docks where
    > its supposed to, but once I move outside the frame, the cursor turns back
    > an arrow, and the toolbar no longer moves if I move back into the frame, I
    > suddenly regain control.
    >
    > I've seen some references on the net where SetCapture() will only capture
    > messages for windows belonging to the current thread, but never saw a
    > reason why or how to work around it.
    >
    > The mouse button IS down when I call SetCapture() as I'm calling it from
    > WM_NCLBUTTONDOWN.
    >
    > I sort of worked around it by installing a Mouse Hook and a Low Level
    > Mouse hook system wide and redirecting messages to my callback window.
    > This worked fine (or so I thought) with only a minor performance hit, and
    > I only left the hooks installed during a drag operation. Recently I
    > noticed it doesn't seem to catch all the mouse movements (like if I am
    > mousing over a DOS window or Media Player).
    >
    > I found another work around by installing a journal hook instead of the
    > other two hooks, but that journal hook seems to cause a bigger performance
    > hit then the other two combined.
    >
    > Seems like the most efficient would be to get the SetCapture() method
    > working... but why is it only trapping messages when the mouse is over my
    > process (or always when the drag is started from a docked position).
    >
    >




  3. Re: Pls Help with SetCapture()...

    Yeah, I saw this, but I am the foreground Window.

    "Ken Wickes [MSFT]" wrote in message
    news:u1Xo2P8OFHA.3704@TK2MSFTNGP12.phx.gbl...
    > Does this from MSDN explain it?
    >
    > "Only the foreground window can capture the mouse. When a background
    > window attempts to do so, the window receives messages only for mouse
    > events that occur when the cursor hot spot is within the visible portion
    > of the window. Also, even if the foreground window has captured the mouse,
    > the user can still click another window, bringing it to the foreground. "
    >
    >
    > --
    >
    > Ken Wickes [MSFT]
    > This posting is provided "AS IS" with no warranties, and confers no
    > rights.
    >
    >
    > "Nobody" wrote in message
    > news:8Nm4e.72085$AN1.24738@fed1read03...
    >> Hi, I'm trying to use the SetCapture() API and am having a few problems
    >> with it. It has worked fine for me in the past, so I'm not quite sure
    >> what the problem is and whether its in MFC or Win32.
    >>
    >> Here is the scenario:
    >>
    >> I'm trying to implement "full drag" MFC control bars. For the sake of
    >> argument a CToolBar. By "full drag" I mean Office 2003 style where the
    >> toolbar is moved around in real time and you can see it completely rather
    >> then the lame stock MFC "outline style drag". I've got this part all
    >> working.
    >>
    >> Here is the problem:
    >>
    >> I can drag the toolbars and they dock, float correctly. When a toolbar is
    >> docked, and I click on the gripper and drag it around, it floats and I
    >> can drag it all around the screen no problem and redock it to my hearts
    >> content.
    >>
    >> BUT... if the toolbar is FLOATING and I go to drag it by clicking on the
    >> caption, I can drag it around too, but I loose control of it if I move
    >> the mouse outside the main frame window?!?!?! What gives??? I no longer
    >> get WM_MOUSEMOVE messages. But if I started the drag from a docked
    >> position, this works perfectly fine.
    >>
    >> So the toolbar is floating, I click on the gripper to start a drag and
    >> the mouse cursor turns to a cross-hair. I drag it across and it docks
    >> where its supposed to, but once I move outside the frame, the cursor
    >> turns back an arrow, and the toolbar no longer moves if I move back into
    >> the frame, I suddenly regain control.
    >>
    >> I've seen some references on the net where SetCapture() will only capture
    >> messages for windows belonging to the current thread, but never saw a
    >> reason why or how to work around it.
    >>
    >> The mouse button IS down when I call SetCapture() as I'm calling it from
    >> WM_NCLBUTTONDOWN.
    >>
    >> I sort of worked around it by installing a Mouse Hook and a Low Level
    >> Mouse hook system wide and redirecting messages to my callback window.
    >> This worked fine (or so I thought) with only a minor performance hit, and
    >> I only left the hooks installed during a drag operation. Recently I
    >> noticed it doesn't seem to catch all the mouse movements (like if I am
    >> mousing over a DOS window or Media Player).
    >>
    >> I found another work around by installing a journal hook instead of the
    >> other two hooks, but that journal hook seems to cause a bigger
    >> performance hit then the other two combined.
    >>
    >> Seems like the most efficient would be to get the SetCapture() method
    >> working... but why is it only trapping messages when the mouse is over my
    >> process (or always when the drag is started from a docked position).
    >>
    >>

    >
    >




  4. Re: Pls Help with SetCapture()...

    Nobody wrote:

    > Hi, I'm trying to use the SetCapture() API and am having a few
    > problems with it. It has worked fine for me in the past, so I'm
    > not quite sure what the problem is and whether its in MFC or
    > Win32.


    This is a real shot in the dark quite but quite some time ago I
    was also having issues with mouse capture. Eventually I tracked
    it down to a obscure bug/feature of Win32?

    If my memory is correct, I found that while the mouse was captured
    calling what looked like an unrelated Win32 API would in fact force
    the the current capture to be released and the only indication of
    this would be the fact that WM_MOUSE message would no longer be
    recieved.

    From memory I think that Win32 API in question was either a call
    to SetCursor or SetFocus.

    Jussi Jumppanen
    Author of: Zeus for Windows, Win32 (Brief, Emacs, etc) FTP Text Editor
    "The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
    Home Page: http://www.zeusedit.com

  5. Re: Pls Help with SetCapture()...

    On Wed, 15 Jun 2005 08:29:21 +1000, Jussi Jumppanen wrote:

    > Nobody wrote:
    >
    >> Hi, I'm trying to use the SetCapture() API and am having a few
    >> problems with it. It has worked fine for me in the past, so I'm
    >> not quite sure what the problem is and whether its in MFC or
    >> Win32.

    >
    > This is a real shot in the dark quite but quite some time ago I
    > was also having issues with mouse capture. Eventually I tracked
    > it down to a obscure bug/feature of Win32?
    >
    > If my memory is correct, I found that while the mouse was captured
    > calling what looked like an unrelated Win32 API would in fact force
    > the the current capture to be released and the only indication of
    > this would be the fact that WM_MOUSE message would no longer be
    > recieved.
    >
    > From memory I think that Win32 API in question was either a call
    > to SetCursor or SetFocus.


    I'd be surprised if SetCursor canceled the capture, but in general you
    should handle WM_CANCELMODE and WM_CAPTURECHANGED. Hopefully one or both
    those messages will tell you when the system takes the capture away from
    you.

    --
    Doug Harrison
    Microsoft MVP - Visual C++

+ Reply to Thread