Corrected the determination of capturing inside EDIT_WM_MouseMove function.

taro-x at justsystem.co.jp taro-x at justsystem.co.jp
Fri May 20 05:02:54 CDT 2005


2005-05-19  Kouji Sasaki  <taro-x at justsystem.co.jp>

> > With only GetCapture() != es->hwndSelf statemet, the string selection will
> occur
> > even if the capturing is done by external processes.
> 
> So what you are saying is that an external process captures the mouse,
> and somehow GetCapture() returns the handle of this edit. Why would
> that happen? How can the external process' window have the same
> handle as this edit? And BTW, what exactly do you mean by external
> process?
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 

I apologize for my choice of words.
The correct way, I hope, would be to say "a process other than the edit control itself",
rather than "the external process".

The message handling in the dialog's window procedure in the previous e-mail would be
an example of "process other than the edit control itself".  The capturing of the edit control
will be set by the window procedure of the dialog, not by the edit control itself.

Hence a process other than the edit control will not necessarily have the same handle as the edit control.

Following through the example in the previous e-mail:

1) Place an edit control in a dialog.

2) Dialog's window procedure handles EN_SETFOCUS message from the placed edit control.

3) When receiving EN_SETFOCUS, the dialog sets the capture of the edit control.
When this happens, the edit control has the focus and capture at the same time.

    >case EN_SETFOCUS:
    >    SetCapture(LOWORD(lParam));
    >    break;

4) When mouse moves over the edit control, a text selection will occur.
In windows, such text selection will not occur.

Hence, the modification was made so that the text selection by mouse movement will only occur when edit control itself sets the capture.

--
Justsystem Corporation <taro-x at justsystem.co.jp>



More information about the wine-devel mailing list