Hi,
Alexandre Julliard wrote in http://www.winehq.org/pipermail/wine-devel/2011-July/090969.html
If you are going to wait for a reply it would be better to create a HWND_MESSAGE window and do a SendMessage to it, then you get all the synchronization for free.
MMSYSTEM_MidiStream_Player needs a patch to fix bug #28388. Such a patch will likely introduce sending Suspend & Resume messages to the MIDI player (to be able to wait for the resume signal). So I believe this same advice applies.
MMSYSTEM_MidiStream_PostMessage already contains a PostThreadMessage + MsgWait pair that looks like it should be replaced, correct?
OTOH, I'm unsettled whether MidiStreamSuspend & -Restart should wait for a reply to the message, so PostThreadMessage may be enough.
Furthermore, I'm unsure about the implications of adding a dummy window and message queue. The MSDN blogs contain repeated warnings about the obligation to pump the message queue and GUI apps hanging when some random app fails to do so in all situations.
Won't that window receive all kinds of broadcast messages? No, says MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/ms632599%28v=vs.85%2...
The MIDI sequencer uses simplistic timing based on GetTickCount. Won't that allow arbitrary foreign window callbacks to disturb the timing of the MIDI sequencer?
Instead of inventing message names like #define WINE_MSM_STOP (WM_USER+1) Why not re-use message names like MCI_STOP even if it's not in MCI format? (sounds like a hack...)
Thank you for your help, Jörg Höhle