I've also tried a lot of other things, but none of the solutions I've
tried work 100% of the time. It sounds like a better idea to have
something that doesn't work consistently than to have something that
inconsistently sort of works. Setting the size in `WM_WINDOWPOSCHANGING`
to (0, 0) fixes the drifting, but the mouse coordinates are still wrong
and `SetWindowPos()` breaks the reparenting.
This reverts commit db2cc5800a.
I think some rounding in Wine is causing this issue, but then again
we're not supposed to send these ConfigureNotify events to the window
directly anyways.
This is needed to support Ardour. These extra hops and serialization
steps will probably hurt performance, but outside of some huge hacks (to
connect the components directly anyways) there's not much else we can
do.
I copied this from the SDK implementation and they don't do any pointer
casts there because it's not strictly necessary, but they're relying on
implementation details that may not always hold true.
It's not necessary, since all of these objects are simple data objects
that will be passed as arguments to other functions. When we have to
pass through one of those functions we can just serialize the objects at
that point.
iZotope plugins will already send messages when connect() is called on
the first object, so this flag has to be set on both host contexts at
the same time.
In the host context. So when the plugin wants to create an `IMessage`
object to send a message to the other object, we don't have to go
through the host.
This has much fewer moving parts, and it's probably more understandable.
There was also a race condition in the previous implementation, so
there's that.
This requires a super hacky workaround because the UI thread can be
currently blocked by the plugin calling `IPlugFrame::resizeView()` from
the Win32 message loop.
This way every relevant object instance will get its own thread for
handling these calls. The alternative would be creating a full fat
Vst3MessageHandler pair for all object instances, but that would be a
huge waste.
Robbert van der Helm