WPFcontrolwrapper resizing

Topics: VST.NET Core
Oct 6, 2015 at 1:47 PM
Hi again,

I have a UserControl wrapped in a WPFControlwrapper, and have created a mechanism for resizing from within the control.
After first resizing the control, I call Host.SizeWindow(control.Width, control.Height), and hosting form obediently changes, but for example, if the size is increased, the increased sections of the width/height are simply black (masking those parts of the control that has also been increased in size).

Thinking that may be the control wrapper instance holding control also needs to be resized, I attempted to do so by resetting the _width
and _height variables of the wrapper, but to no apparent effect...

Thinking that perhaps the HwndSourceParameters that are set in the wrapper Open sub need to be reset too, i tried declaring them outside the sub, and then later updating the width/height of that HwndSourceParameters, but the black (control-covering) portions still remain.

(just sure I'm missing something obvious)
Coordinator
Oct 6, 2015 at 2:12 PM
Sounds like the windows is not invalidated and thus redrawn. You could try to invalidate the parent HWND...?
https://msdn.microsoft.com/en-us/library/dd145002(v=vs.85).aspx
Oct 6, 2015 at 3:14 PM
I tried the InvalidateRect function passing the "MyHwndParams.ParentWindow" as hWnd and IntPtr.Zero as the rect pointer but no dice :-(
Incidentally in addition to changing the Width/Height of the HwndSourceParams I also tried SetSize(newwidth, newheight), with no difference in results... wonder what is the difference between just setting HwndSourceParams.Width/Height and using SetSize...?

Anyway there does seem to be something else going on rather than just a window invalidation.
In addition to the behavior I described is you increase the width or height, what happens when you decrease it is that now the top (or left) of the control becomes offset with respect to the Host window! (by the amount you decrease it).
This leaves black on the top (or left) of the Host window, with the control being clipped off at the bottom (or right) by the edges of the Host window.

This may be a little difficult to visualize so perhaps a jpg might be in order. (Can upload if necessary)

I don't why the top/left positions would be affected, since only the size values are being changed !
Coordinator
Oct 6, 2015 at 3:31 PM
Hmmm, not sure what is going on.

I would suggest you try searching WPF forums which deal with hosting in WinForms or WIN32...
Oct 7, 2015 at 10:04 AM
Went searching, and what a rabbit hole that was :-)
But I finally found the problem... and a workaround solution.
BTW, sorry i was thinking it had something to do with the Core.dll but you're right it's totally a WinForms/WPF issue.

Seems that resizing WPF forms hosted in winforms runs into problems with how pixels are handled, and some other stuff i don't understand.
Anyway, just in case anyone is trying to do the same thing (resize the host window) and runs into the same problem, here's what i (successfully) did.
Since the wrapper doesn't like to resize properly, whenever you call a resize within the UserControl, after resizing the Host by Host.SizeWindow, you create a New WpfControlWrapper with the new size. And of course you have to ".Open" it.
But this time in the _editorCtrl.Open Sub, instead of _instance = New T(), you have to set _instance to be your original UserControl (the same one that invoked the resize).
Basically, recreating a new wrapper in the host and attaching your same UserControl to it.
It works!

Only one avoidable issue is that if your resizing mechanism involves the mouse (like a slider bar), once the new editorCtrl is created your mouse events get disposed of (at least that's what i think is happening), so the slider only moves a little each time, which is a bugger, and means a slider isn't very effective.
There might be a better way, but I found using buttons works best. Clicking them to widen or shrink the window.

Maybe VSTs aren't really designed to be resized at runtime, but at least it is possible, if anyone needs to do it.

Cheers,
Michael