For Windows: process WM_APPCOMMAND messages

[Mercury048]

It would be really nice if VLC could process and take action on WM_APPCOMMAND messages. A lot of 3rd party software, especially for multimedia keyboards and remote controls and the like send these out. (I'm specifically thinking of my ATI remote). SImple stuff like play/pause/stop and adjusting volume would make a huge difference.

There aren't that many messages to handle (you'd only need to implement the ones dealing with multimedia) and I don't think it would be that difficult to code this, and it would increase the it-just-works factor.

How about it?

[Jean-Baptiste Kempf]

Patches are welcome.

[VLC_help]

It these should go to events.c, I can create patch. (bump this thread up on next weekend if I haven't replied earlier)

[Mercury048]

I took a look at the VLC source... wow I'm in way over my head. I'm not a "developer" as such though I have built simple (one *.c file) apps that do simple things.

Basically this code should be placed in a GetMessage loop - simple text search shows these loops are present in events.c, wince.cpp, win32_specific.c and win32_loop.cpp. I'm not sure exactly which one(s) it should go into.

It should look something like this: (Note this is a horrible attempt at something that looks like code, I hope you get the point)

Code: Select all

while( GetMessage( &msg, NULL, 0, 0 ) ) { //some pre-existing stuff goes here? switch( msg.message ) { case WM_PAINT: //or whatever { // pre-exiting code here, there will be several case blocks } // ...more pre-existing code... case WM_APPCOMMAND: // this is what I'm talking about { cmd = GET_APPCOMMAND_LPARAM(msg.lParam); switch(cmd) { case APPCOMMAND_MEDIA_STOP: { //call whatever code to stop playback } case APPCOMMAND_MEDIA_PLAY_PAUSE: { //play or pause the playback depending on current sate } case APPCOMMAND_MEDIA_PLAY: { //begin playback, do nothing if already playing } case APPCOMMAND_MEDIA_PAUSE: { //pause playback, do nothing if already paused } case APPCOMMAND_VOLUME_DOWN: { //lower the playback volume } // and so on for all the relevant messages } }

[VLC_help]

Yep, events.c isn't the right one, because it would only work with videos.

[VLC_help]

I added them to win32_specific.c, but I am not sure if they work. (winuser.h that comes with cygwin/mingw doesn't seem to include all needed stuff, so I just used some #DEFINEs)

If you have some software (or know one) that I can use to send those messages, it would help =)
Currently I have added CASE for APPCOMMAND_MEDIA_STOP, APPCOMMAND_MEDIA_PLAY_PAUSE, APPCOMMAND_MEDIA_PLAY and APPCOMMAND_MEDIA_PAUSE

APPCOMMAND_MEDIA_STOP is the only one that should actually do something nice, others just print warn messages to message log (Tools -> Messages and Verbosity to 2)

http://rapidshare.com/files/142333889/v ... s.zip.html

[Mercury048]

Thanks, I will test this later today when I get home. As for a test app, you should be able to simulate it with one line of code:

Code: Select all

PostMessage(GetForegroundWindow(), WM_APPCOMMAND, (APPCOMMAND_STOP << 16), GetDesktopWindow());

assuming VLC has focus or:

Code: Select all

PostMessage(HWND_BROADCAST, WM_APPCOMMAND, (APPCOMMAND_STOP << 16), GetDesktopWindow());

Again, I'll try this later today with a real commercial app.

[Mercury048]

Unfortunately I was not able to run that version of VLC. It crashes immediately upon start - I don't even see the GUI.

[VLC_help]

What OS are you running?

[Mercury048]

Windows XP SP3.

[VLC_help]

I will update to SP3 tomorrow and see if that causes some issues.

[VLC_help]

I also forgot, if you use skins as default interface, nigtlies won't start because skins2 support is broken ATM.

[VLC_help]

I updated to XP SP3 today, and so far no issues. So XP SP3 should work with that build.

[Mercury048]

How do I use another interface? I assume it's the --intf option but what value should I use?

[VLC_help]

Code: Select all

vlc.exe --intf qt4

hopefully that works.

[Mercury048]

Nope, the thing refuses to start up. Interestingly, I get no error messages now, no matter what interface I specify. The last time I got the standard windows crash message - "vlc has peformed blah blah blah and needs to close, send error report to MS...". It may have had something to do with the fact that I had an instance of VLC 8 open?

Right now, when I try to run it, I can see the vlc process in task manager. It runs for about 5 seconds and then dies, never showing any UI or messages. I even tried in a virtual machine with a clean XP install - same thing. :-/

I'd really like to see this work. Is there anyway you could try your code into a more stable branch (like 9.x?)

Point of interest: Media Player Classic (also open-source AFAIK) seems to handle these messages correctly.

[VLC_help]

You tried to remove %appdata%\vlc folder before starting?
EDIT:
I add stuff to nightlies because new feature window is already closed for next stable. Also I like to check out git every now and then to see it still functions
EDIT2:
I think I can use http://johnbokma.com/mexit/2007/01/22/a ... -perl.html and http://cc.codegear.com/item/25888 to test this.

[Mercury048]

Nope, no go. There is probably something I'm doing wrong but I can't figure it out.

Actually, I just realized... I think that the GetMessage loop only retrieves messages from the message queue, that is, posted messages (via PostMessage), not sent messages (via SendMessage).

I may be wrong here, but I think the way VLC currently handles window messages is not right. The GetMessage loop should still be there, but there should be very little in it besides TranslateMessage and DispatchMessage. All the message handling code should be moved to the window procedure.

Win32Proc in win32_factory.cpp - is this specific to the skins2 interface?
DirectXEventProc in events.c
CBaseWindow::BaseWndProc in wince.cpp
VLCInPlaceClassWndProc in plugin.cpp

[VLC_help]

I will look these more on weekend. win32_factory.cpp should be for skins interface only, because it is in skins2\win32

[Mercury048]

I did a bit more research on this issue, especially since I think it is affecting others (see here) and I think this rises to the level of a bug, not just a feature request.

For the skins2 interface, the message handling code needs to be moved to the window procedure as I mentioned. The GetMessage loop should call TranslateMessage and DispatchMessage, which will simply pass the message to the window procedure where it will be handled. This is the "proper" way of doing things in Windows as it handles both posted messages (which are retrieved by GetMessage) and sent messages (which are sent directly to the window procedure).

Now QT4 is a bit of a problem. After a bit of research it seems that QT4, in an attempt to be platform-independent, does not allow windows to receive OS messages directly, instead, it translates messages into QEvent objects which are then passed to the window. Here is where I'm lost - I don't know if the QT framework even handles WM_APPCOMMAND messages in any useful way. If it does, I have no idea what the QEvent object is supposed to look like.

RIght now it seems that VLC 0.9.2 using the QT interface is "eating" WM_APPCOMMAND messages. They are obviously not being processed but neither are they allowed to fall through to the OS. They are simply lost at some point. Whether this is due to something intrinsic to the QT framework or some kind of "failure to communicate" between QT and VLC, I don't know. This I think is a bug, because existing functionality is being broken. It needs to be fixed somehow.

[VLC_help]

Thanks for the info.
http://doc.trolltech.com/solutions/4/qt ... ample.html
maybe that helps somewhat.

[Mercury048]

I will look into this some more later. I notice a bug has been filed, and I believe this issue is the cause:
http://trac.videolan.org/vlc/ticket/2086

[VLC_help]

winEventFilter should provide help for this, I just can't find any good sample code for this.
http://doc.trolltech.com/4.1/qcoreappli ... ventFilter

[Mercury048]

Thank you very much for staying interested in this!
Try this:

Code: Select all

winEventFilter ( MSG * msg, long * result) { switch(msg->message) { case WM_APPCOMMAND: cmd = GET_APPCOMMAND_LPARAM(msg->lParam); switch(cmd) { case APPCOMMAND_MEDIA_STOP: /*....identify and process the command here...*/ } *result = TRUE; //The value we want the window procedure to return (Windows expects TRUE here; see WM_APPCOMMAND documentation) return true; // we don't want Qt to handle this message default: return false; // other messages should be handled by Qt }; }

[VLC_help]

I can process the messages now.
1. viewtopic.php?f=14&t=50179 that should be fixed now.

2. Should we make this WM_APPCOMMAND stuff user selectable? So if someone doesn't want global controls, they can disable those.