Reimplementing winEvent: getting stuck in API call

JulienMaille

I am trying to build a bridge between two API:

one communicates through sendMessages
the other one is accessible through an activeX

This is what I do: @ HRESULT hr = pMJ.GetActiveObject(L"MediaJukebox Application");
pPlayback = pMJ->GetPlayback();
pPlayback->Play();@
The Play() call works perfectly.
Then I connect a pushButton to a slot that will also call pPlayback->Play(), it works.

Finally I reimplement winEvent(...) to receive message from the other program. @bool Bridge::winEvent(MSG *message, long *result)
{
if( message->message == WM_USER )
{
pPlayback->Play();

    *result = 0; // keep the event from qt
    return true;
}

// give the event to qt
return false;

}@ Here for some reason, the Play() call never returns. I'm stuck indefinitely in it!
In the meantime I can click my pushButton, and this one will work. But within winEven(...) it doesn't.

What is the issue there? Am I triggering an infinite recursion?

giesbert

Hi neFAST,

are you in an infinite loop (which could mean Play also emits a WM_USER event) or does it only "not work"? You should check the window, that gets the message here. Which type has bridge? Widget? QApplication derived? ...

JulienMaille

Thanks for your help.
How can I check the window that gets the message?
Bridge is a QMainWindow

EDIT: I tried a mutex-like in winEvent(...)
@ if( message->message == WM_USER )
{
if( !CDArtMutex )
CDArtMutex = true;
else
return false;
pPlayback->Pause();
emit handleCDArtEventUser((int)message->lParam, (int)message->wParam, result);
*result = 0;
CDArtMutex = false;
return true;
}@
This does not solve the issue.

giesbert

The point is that you only check one members of message...
message also more members:

hwnd Handle to the window whose window procedure receives the message.
message Specifies the message identifier.
wParam Specifies additional information about the message. The exact meaning depends on the value of the message member.
lParam Specifies additional information about the message. The exact meaning depends on the value of the message member.
time Specifies the time at which the message was posted.
pt Specifies the cursor position, in screen coordinates, when the message was posted.

you could compare hwnd with the "winID()":http://doc.qt.nokia.com/4.7/qwidget.html#winId of your main window.

Why the mutex does not work is also simple: if play doies not send the event but post it, it will arrive after you exited the event handler...

JulienMaille

I'm not sure to understand your 2 remarks:

ok let's say I detect event sent by my main window. What should I do? Discard them?
what would be the problem if the event posted by play() arrive later on?

Sorry for these silly questions, I feel kinda lost.

giesbert

Each WM_USER evtn is handled by you regardless who is the receiver of the event. Afterwards you throw it away by returning true (handled).
And for each WM_USER event you call ->play().

I suggest the following:

@
if( (message->message == WM_USER ) && (message->hwnd == winId()) )
{
pPlayback->Pause();
emit handleCDArtEventUser((int)message->lParam, (int)message->wParam, result);
*result = 0;
return true;
}
@

Doing this you only react on WM_USER messages send to Your window.

JulienMaille

I will try to filter messages addressed to my winId.
But I still don't understand why I have this strange behavior. I have run the msvc debugger step by step. When I reach play() and press the "next step" button, it never returns from play().
I simplified my code to post it in a more readable format. I already perform some filterning, but not on the winId. So maybe this will fix the issue.

EDIT: filtering with the winId() did not solve my issue...

JulienMaille

I stepped into the Play() call and found this:
@inline HRESULT IMJPlaybackAutomation::Play ( ) {
return _com_dispatch_method(this, 0xf, DISPATCH_METHOD, VT_EMPTY, NULL, NULL);
}@

giesbert

[quote author="neFAST" date="1311766193"]I stepped into the Play() call and found this:
@inline HRESULT IMJPlaybackAutomation::Play ( ) {
return _com_dispatch_method(this, 0xf, DISPATCH_METHOD, VT_EMPTY, NULL, NULL);
}@[/quote]

This only shows that play is a COM call, but what does it do internally?

JulienMaille

I don't know I do not have access to this source code.
I suspect that when I call play() from my winEvent(...) reimplementation I am not in the main thread and this causes the problem.

giesbert

your events of UI widgets are always in the main thread, onlöy if sendEvent is used and not post event, it is possible to be outside the main thread.
But typically in Qt, everything that is UI relevant happens in the main thread, and this includes the events handlers. This is a MUST.

JulienMaille

Ok then what could explain that play() returns correctly when started in a slot connected to a button in my GUI. And it blocks when called within winEvent()?

JulienMaille

You were right, everything stays in the main thread. How can I figure out if the COM control fires an event that is caught by winEvent in a recursive way?

With our without my stupid mutex, the test() call is never reached !?

@if( message->message == WM_USER && message->hwnd == winId() )
{
if( !CDArtMutex )
{
CDArtMutex=true;

        pPlayback->Play();
        test();
        CDArtMutex=false;
        *result = 0;
        return true;
    }
    else
    {
        // give the event to qt
        return false;
    }
}@

giesbert

That can have multiple reasons, and I can't tell you from that small code fragment. If you provide a small, minimal example showing this that can be compiled, then perhaps.

JulienMaille

My code is really minimal but it is a bridge between 2 applications: if you want to test it you will have to fire messages. Keep in mind it is windows only.
I uploaded an archive here: "hotfile":http://hotfile.com/dl/125174202/8234364/CDArt-JRMC.zip.html
You will see that I got something working with QTimer::singleshot() but this is not a real solution since I can't pass any arguments to my slots. So it is working for Play() but not for other calls.
Thanks again for your kind help!

giesbert

i,

I looked a bit into your code but saw no direct bug, but I also have no idea how this CDART and JRMC stuff works, sorry.

JulienMaille

I got this answer from JRMC:

[quote author="JRMC" date="1311799775"]Using PlaybackAutomationPtr from a worker thread could cause trouble, because internally it sends messages to the player window. Especially if the handling of these messages fires an event that tries to re-enter your event handler.

Instead, I would recommend posting MCC messages to the player if you're in a worker thread.

For example:
PostMessage(MJ.GetWindowHandle(), WM_MC_COMMAND, MCC_PLAY_CPLDB_INDEX, -1);
[/quote]

PostMessage is ok for Play() Pause() commands, bu it wont work when I need to retrieve informations from the COM.

JulienMaille

I got something working by following these tips:
http://stackoverflow.com/questions/1755196/receive-wm-copydata-messages-in-a-qt-app

BTW the code I uploaded was full of bugs, I was emiting slots!

JulienMaille

2 remarks:
_I had to connect my re-emitted signal to a custom slot with "Qt::QueuedConnection":http://doc.qt.nokia.com/latest/qt.html#ConnectionType-enum. Otherwise it does not work.
_I am supposed to return values to the API through the winEvent(MSG* msg, long* result);
However, since I have to re-emit from winEvent to get this working, winEvent() returns before I set the long* result to the desired value. So I'm stuck once again.

JulienMaille

I have changed the way I interface the COM object, and now with this code: @bool Bridge::winEvent(MSG *message, long *result)
{
if( message->message == WM_USER && message->hwnd == winId() )
{
myQAxObject->dynamicCall("Play()");
return true;
}

// give the event to qt
return false;

}@ I get this error: "QAxBase: Error calling IDispatch member Play: Unknown error"

While if I call myQAxObject->dynamicCall("Play()"); from anywhere else in my code it works.