"Peter de Vroomen" <peterv[at][spamblock]jaytown[dot]com> wrote in message
news:42b834a4$0$32070$e4fe514c@news.xs4all.nl...
> Hi,
>
> I have a floating EditBox (a TextBox on a borderless Dialog) over a
> ListView. I wish to capture the mouse events so I can detect if a user
> clicked outside of the EditBox. I show the floating EditBox as modal, so
> the
> underlying form with the ListView is deactivated. When I click outside the
> EditBox, I need to remove it and reactivate the underlying form.
>
> I therefore set the Capture property of the EditBox to True. On MouseDown,
> I
> check if I clicked inside or outside the EditBox, and deactivate the
> floating EditBox when the click was outside (remember, it's actually a
> TextBox on a Dialog, so I just return a DialogResult of Cancel, and the
> underlying form is reactivated). This works fine.
>
> However, when I click INSIDE the EditBox with the left mouse button, the
> Capture property is reset to False by the .NET Framework. From then on any
> click outside the EditBox results in a *ping* because the mouse click is
> sent to the underlying (deactivated) form instead of captured by my
> EditBox.
>
> No matter what I try, the Capture property is reset to False *after* the
> MouseUp event finishes. It actually doesn't matter where I click, the
> Capture property is simply forced to False after the MouseUp event
> finishes.
> Apparently the framework itself is resetting the Capture property after
> the
> MouseUp event returns.
>
> So I thought to override the TextBox class and the OnMouseUp event. In the
> OnMouseUp event, I force the Capture property to True. Like this:
>
> Public Class ctrlCustomTextBox
> Inherits TextBox
>
> Protected Overrides Sub OnMouseUp(ByVal e As MouseEventArgs)
> MyBase.OnMouseUp(e)
> Capture = True
> End Sub
> End Class
>
> But to no avail, Capture still gets reset after the sub OnMouseUp returns.
>
> I then chose to not call MyBase.OnMouseUp(e), risking all sorts of
> unexplained behaviour. But that had absolutely no effect either.
>
> So, I have reached the end of my knowledge. Anybody have an idea what I
> can
> do?
>
>
> --
> Regards,
>
> Peter de Vroomen
> Software Engineer
> Jaytown
> http://www.jaytown.com
>
>
>

> My guess is that it's the dialog stuff that mess things up
> Why do you need your textbox to be on a dialog?
> Since it's borderless you can't move it anyway so why not
> make the textbox a child of the listview?

> If you still want to use the dialog approach, have you tried
> closing it when the textbox and/or dialog looses focus instead?

> Your idea with a transparent dialog might work aswell. Might even
> be easier

"Peter de Vroomen" <peterv[at][spamblock]jaytown[dot]com> wrote in message
news:42b933f5$0$32071$e4fe514c@news.xs4all.nl...
>> My guess is that it's the dialog stuff that mess things up
>> Why do you need your textbox to be on a dialog?
>> Since it's borderless you can't move it anyway so why not
>> make the textbox a child of the listview?
>
> Hmm, I did think of that. But it was easier to do it with a dialog. For
> one,
> I can work with the class wizard (or whatever it is called these days :)).
> But most important is that a dialog can be modal. So showing the textbox
> modal automatically disables it's parent dialog.
>
> If I would use a child textbox, I would have to override the message
> handler
> to eat up any messages that would be sent upwards to the parent control,
> wouldn't I? I know how to do that in C++, but not in VB.NET.
>