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? …

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(…)

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() [doc.qt.nokia.com] 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…

I’m not sure to understand your 2 remarks:
1. ok let’s say I detect event sent by my main window. What should I do? Discard them?
2. what would be the problem if the event posted by play() arrive later on?

Sorry for these silly questions, I feel kinda lost.

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:

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

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…

I stepped into the Play() call and found this:

neFAST wrote:

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); }@

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

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.

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.

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()?

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 !?

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.

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 [hotfile.com]
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!

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.