VB.NET: Editbox Capture mouse event allways forced to false after MouseUp?

[Peter de Vroomen]

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

 

[Claes Bergefall]

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?

/claes

 

[Peter de Vroomen]

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.

But I guess it is worth a try, how hard can it be anyway?

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

Yes, but sadly it's not that easy. Clicking outside the textbox does not
make it lose focus, as you would click on the parent of the dialog on which
the textbox lies. And that is deactivated. And alt-tabbing *would* make it
lose focus, which would close the textbox. Although, that could be explained
as a feature .

Hmmmm, I just thought of something. A dialog could be made transparent. I
could try to make the dialog of the textbox transparent and as large as the
client area of my program or the listview. Clicking on the client area of
the program would make the event go to the textbox's dialog. No need to
capture the mouse events, and clicking outside of the client area (or maybe
the whole window) of the program would not make the textbox disappear.

I guess I'll try that first. If it doesn't work as desired, then I guess
there's no other option than to try your first suggestion.

Thanks for your reply!

PeterV

 

[Claes Bergefall]

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.

I'm not sure what you want to accomplish but I don't think you need
to eat the messages sent elsewhere. The "close on lost focus" idea
works fine when the textbox is a child of the listview (that's what I
did when I needed a listview that allowed subitem editing). No need
to prevent any of the normal message flow.

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

/Claes

 

[Peter de Vroomen]

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

Ahem, well, it *would have* worked if the designers at Microsoft would have
taken the meaning of 'transparent' as being 'see-through'. Apparently, for
Microsoft designers 'transparent' means 'not-there', just like 5-year old
kids do :+). I guess they don't have transparent glass doors in Redmond.

Anyway. The effect is that if the dialog that hosts the texbox is not
transparent, the mouse events are sent to the dialog and I can catch them
and make things work. But when I turn the dialog box transparency on, the
mouse events are sent to the parent of the dialog (which is deactivated,
etc. etc.).

I guess I'll have to go for the option of making the textbox a child of the
listview. I guess I'll have to make an inherited textbox class to be able to
catch the messages I need and to create the textbox dynamically (using the
CreateControl member).

Thanks for your suggestions!

PeterV