Apologies Brian, I had pretty much proven that Sizer wasn’t the issue before you were contacted. I ran a few tests and quickly realised that Sizer was mealy highlighting the issue. Those tests narrowed down the culprit (use of WS_SIZER for min sizing) and identified a solution (use WM_GETMINMAXINFO instead).
It’s a great little app, it’s worked flawlessly for years. No worries about the update any time soon, I’m sure its quite an edge case considering it will only happen on windows apps that don’t utilise WM_GETMINMAXINFO for min sizing.
I do however appreciate you taking the time to put some additional clarity forward, this thread has gone on waaaay longer than I expected for such a minor issue that I could work around a few days ago 
Thank you Brian. If anything, this was the occasion to discover your work
[quote=262378:@Brian Apps]I exchanged an email with Mitch and he kindly asked if I was happy to make it public. I am so here it is:
I can see both points of view in this thread. Mitch is saying Sizer has stopped things working. Julian is saying WM_SIZING is not designed to limit window dimensions. I rather that Sizer is removed from the argument Instead consider the case when a window is resized by something other than the mouse i.e. someone uses a function like MoveWindow(). In this case a WM_SIZING message is not sent to an application. Therefore the current Xojo behaviour will not honour the min/max settings. If WM_GETMINMAXINFO is handled then things work in all cases. Whether this is a defect or a feature is something I’ll leave to the Xojo people to decide.
Thanks
Brian[/quote]
Thank you for looking into this and taking the time to write up what you found. It does sound like the Xojo framework is doing something strange (and potentially incorrect).
Just for completeness (and if someone searches this topic) I have found a bug in this code that causes a crash on x64
Structure POINT
X As Integer
Y As Integer
End Structure
should in fact be
Private Structure POINT
X As Int32
Y As Int32
End Structure