Question about messages and the windows these need.

[Joerg-Cyril.Hoehle at t-systems.com]

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%29.aspx#message_only

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