libVLC1.10 for Windows: Event handling

[Jo2003]

If you use functions libvlc_video_set_key_input and libvlc_video_set_mouse_input to let your own application handle the keyboard and mouse events, you'll find that no more event is handled by libVLC but also there is no event sent to your application. You can make it work with low effort. Event handling is done in modules/video_output/msw/events.c

Find following code around line 288 (function Eventthread):

Code: Select all

if( !b_mouse_support && isMouseEvent( msg.message ) ) continue;

Replace it with:

Code: Select all

if( !b_mouse_support && isMouseEvent( msg.message ) ) { /* * if there is a parent window, post message to it! */ if( p_event->parent_window != NULL ) { /* * Messages we don't handle directly are dispatched * to the parent window using the window procedure */ PostMessage(p_event->hparent, msg.message, msg.wParam, msg.lParam); } continue; }

Find code around line 291:

Code: Select all

if( !b_key_support && isKeyEvent( msg.message ) ) continue;

and replace it with:

Code: Select all

if( !b_key_support && isKeyEvent( msg.message ) ) { /* * if there is a parent window, post message to it! */ if( p_event->parent_window != NULL ) { /* * Messages we don't handle directly are dispatched * to the parent window using the window procedure */ PostMessage(p_event->hparent, msg.message, msg.wParam, msg.lParam); } continue; }

These changes make sure that the event isn't ignored but forwarded to the parent window. After compiling the sources your changes will be in libdirect3d_plugin.dll.

Best regards,
Jörg

[Jean-Baptiste Kempf]

Jörg,
Would you be nice enough to create a diff and a patch and send it to vlc-devel@ so that we can have it in VLC 1.1.1 ?
Please?

I'll do my best to have a 1.1.1 out quite soon.

[erwan10]

Beware. Just posting the mouse event is not sufficient. You need to recompute the lParam (mouse coordinates) with respect to the parent window. Also, there are not one but two subwindows

[Jo2003]

@erwan10
Did you try it? Mouse works and keyboard as well. Of course I may miss something. I only thought I can give a hint if someone has the same problem. So, please, since you know how it should work, tell us how to make it right. Thinking about the coordinate mapping for the mouse... the question is: How does the parent window differ in coordinates? If you have embedded the video output into any widget, the coordinates shouldn't differ since libVLC uses the size and position of the parent widget. Or did I miss something? Please tell.

@j-b
We better wait for erwans suggestions. I don't want that untested or buggy code becomes part of VLC.

Thanks in advance,
Jörg

[erwan10]

I do have such a patch, and it works fine, but I don't think it is the right solution.

first, it is a hack to work out a deeper design issue (multiple threads for the GUI). I would rather work out the root problem than work around its effects.

Second, on msdn site, there are warnings against using this method
(see http://blogs.msdn.com/b/oldnewthing/arc ... 23202.aspx)
Since the purpose is to offer a library (libvlc), it has to behave as expected whatever the use.

third, liblvc users can use global hooks to get those messages anyway. vlcj java implementation did it already, iirc.
So, not a blocking issue for libvlc developpers.


excerpt:

Other issues with using PostMessage to simulate keyboard (or mouse for that matter) activity are:

Keyboard and Mouse hooks will not get called. These hooks only get called for "real" mouse and keyboard input (keybd_event, mouse_event and SendInput are all alternate ways of generating "real" keyboard and mouse input).

The queue state (obtained using the GetQueueStatus API) will not reflect the correct state.

If you are waiting using the MsgWaitForMultipleObjects API and have specified QS_KEY or QS_MOUSE as your wake mask, you will NEVER be woken up.

Basically a posted message of WM_KEYxxx or WM_MOUSExxx is just that, a posted message. It will be treated as one by Windows. Of course, you will still be able to fool most applications using PostMessage because most applications simply call PeekMessage or GetMessage and use the resultant message.

[Jo2003]

Fine with me. For me it was important to have a working solution right now. I don't say: Put it into vlc sources. It was an info for someone who is interested in. Not more or less.

Thinking about converting the messages into some SendInput() stuff inside libVLC doesn't sound any better to me.

Thinking about a library which provides video playback ... there is always a need to make a compromise. I want to use it - I must do it the way it is expected by the library. And piped messages (using PostMessage() ) - this is much better then no message at all. At least I think so.

Best regards,
Jörg

[rayner_pupo]

Jo2003 or some one else: can you send the libdirect3d_plugin.dll library recompiled for me. I'm not vague just I don't have enought internet to download the vlc sources to recompile