Mouse Capture

[Guest]

Hi,

I have code that "pops up" a listbox control. It's a child of my topmost
form, and appears on top of other controls. I would like to hide the listbox
when the user taps on an item in the list (on MouseUp), or taps outside the
listbox (on MouseDown).

Of couse, ListBox doesn't support the mouse methods. Setting Capture=true
and attaching a MouseDown delegate to the main form only works to a point (if
the user taps in another control, or on the menu bar, there's no
notification).

I wrote a native DLL that calls SetWindowsHookEx and passes mouse messages
to a managed MessageWindow. It turns out that mouse hooks are not implemented
in WinCE.

Am I missing something, or have I done something wrong? I see that the
ComboBox drop-down list manages this, as does the SysDateTimePick32 control.

It looks like OpenNETCF ApplicationEx class would allow me to create an
application-wide message filter for the lifetime of the ListBox. Could
someone confirm that this will pony up those pesky mouse messages?

 

[Guest]

An IMessageFilter should give all messages your apps message pump gets, so
it should get them.

 

[Guest]

Thanks Chris. I gave it a try, and it worked like a charm.

Unfortunately, there seem to be some compatibility issues between
Form.ShowDialog and the ApplicationEx replacement... the most confusing being
that the form's main menu gets disabled (apparently by the call to
ThreadWindows.Enable).

The form.Show call (before the ThreadWindows stuff) raises the Load event,
so unless I'm forgetting something, there's no opportunity to attach the menu
later.

I worked around this by modifying ApplicationEx to remove and reattach the
menu, but I'm curious about the purpose of ThreadWindows (what exactly is it
supposed to disable?), and wonder if this issue has been resolved in SDF 2.

 

[Guest]

I know some issues with ShowDialog were handled in the past, but I don't
recall if they were in 1.4 or post 1.4. I do know you must use the
ShowDialog method in ApplicationEx/2 not, the Form's ShowDialog, as it would
circumvent your message pump, making it impossible to get messages for the
modal dialog.

 

[Guest]

I bought a copy of SDF2 to take a look at Application2, but nothing has
changed that would explain/eliminate the disabled menu problem I'm seeing.

This has me baffled. If this were a common problem, you'd probably have
heard about it ;-)

I added code to ThreadWindows.EnumThreadWindows to gather info on the
windows being disabled, and sure enough, if my form has a menu, it disables
what appears to be the associated "menu_worker" window (its parent is my
form).

It also disables the form that's currently active, and its "menu_worker"
window.

I notice that my form has no parent, which affects the result of
GetTopWindow in EnumThreadWindows. I'm not sure how (or if) forms are
normally parented, but explicitly setting its Parent property to the
underlying form seems to break things (the form is not even drawn).

For now, I've modified EnumThreadWindows to skip windows who's are children
of the specified parent form. This seems to solve the problem, without the
overhead of removing and re-creating the menu, but I'm not comfortable being
clued out :-(