Reimplementing winEvent: getting stuck in API call

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.