Whatever you believe, fact is without Sizer Xojo behaves as expected. When Sizer is used, things go wrong.
To keep the comparison, Xojo can only design its apps to run on plain Windows. If you add something that makes it slip, how in hell could that be its fault ? How on earth would it be possible to imagine the kind of things that are done under the hood that have never been documented by Microsoft ?
As a matter of fact, your very thread is a demonstration that Sizer does things that perturbate Windows itself : why is it documented system calls all the sudden stop working as expected when it is here ?
I am not saying Sizer is bad in itself. Simply that it probably does things that are not quite kosher. My first reflex would be to contact the author and ask what can be done to prevent the issue, since it is not open source.
Its messing up this one.
You think its a bug in Xojo because you have source code in Xojo.
If it was causing this to happen in Internet Explorer or Word, or Photoshop, then you would be talking to ‘Brian’ about it.
The (briefly read) description says it is designed to set a window to a specific size.
Did you tell it to change the size of the Xojo app’s window?
If no, isnt that a bug right there?. It shouldn’t be hooking the Xojo app…
The documented system call doesn’t stop working as expected any more, it was a pointer reference issue on my part, I have correct code in there now and I have now got a running program in xojo that (here is the key part) overrides xojo’s UI framework for controlling minwidth and minheight and this program doesn’t get effected by Sizer any more.
Therefore, through the process of elimination I can rightly assume that its Xojo’s native UI framework that could be to blame as it doesn’t happen in any other case whether using a different programming language or app.
On the flip side, why would I bother the developer of Sizer when the issue only occurs when using Xojo’s UI framework to control the minwidth and minheigh of a window, which has proven to be the issue as I can circumvent it using my code above and everything works fine?
Why indeed should you report to a fellow programmer any potential issue with his utility damaging other unsuspecting apps ?
I am glad you were able to fix the issue.
Now what would be real nice and useful is to post the final code, as well as the way the method is supposed to be called, so others searching the forum can find the solution to a similar problem. Including of course the MINMAXINFO structure. Ideally, a project demonstrating.
If the problem existed in anything other than an app made using Xojo, I would. As it doesn’t I’ll wait and see what Xojo say about it.
<https://xojo.com/issue/43575>
[quote=262008:@Michel Bujardet]I am glad you were able to fix the issue.
Now what would be real nice and useful is to post the final code, as well as the way the method is supposed to be called, so others searching the forum can find the solution to a similar problem. Including of course the MINMAXINFO structure. Ideally, a project demonstrating.[/quote]
My original question was how to interact with the returned MINMAXINFO data which was answered and marked as such at the top of the page. But as I’m new here and couldn’t find a simple example of what’s happening here I’ll change the thread title and include a little sample app to help someone else trying to do a WndProc handler.
WM_GETMINMAXINFO Example Project
Once again, thanks everyone who helped.
[quote=262036:@]My original question was how to interact with the returned MINMAXINFO data which was answered and marked as such at the top of the page. But as I’m new here and couldn’t find a simple example of what’s happening here I’ll change the thread title and include a little sample app to help someone else trying to do a WndProc handler.
WM_GETMINMAXINFO Example Project [/quote]
Thank you so much.
I also sent a message to BrianApps about this thread.
Julian, I don’t know if this can be useful (I used lparam and WndProc), but just in case:
https://forum.xojo.com/31205-mid-button-mouse-wheel-dragging-solved
Ramon, nice! Thanks for that, it’s nice to see a different way of doing things. I’ll keep that snippet, I’m sure it’ll come in handy soon!
Ramon, no need to use a link yours was misconfigured and pointed to example.com. Just paste and the forum will do the rest :
https://forum.xojo.com/31205-mid-button-mouse-wheel-dragging-solved
OK. Got a message from Brian. Next version of Sizer (Sizer 3.x) should not have the same issue.
[quote=262095:@Michel Bujardet]Ramon, no need to use a link yours was misconfigured and pointed to example.com. Just paste and the forum will do the rest :
https://forum.xojo.com/31205-mid-button-mouse-wheel-dragging-solved[/quote]
Thanks Michel.
Wow, did he indicate what the issue was? I’ll let you know if its fixed in the next version as Xojo has verified the problem in the bug ticket.
If he did indicate what the issue was, please attach that information to the bug report. It would probably save us a bit of time when we go to fix it.
He said that Sizer was very aggressive, hooking the WM_SIZING message, and he will proceed otherwise in Version 4.x, but he is developing Version 3.x at the moment. He did acknowledge there could be side effects to the technique he uses, which he qualifies as “quite intrusive”.
His advice for the time being is to uncheck “show tooltip when resizing windows” in Options.
It always pays to write to a fellow developer, as a peer. We always like to get that kind of input.
I cannot post his message, as it is a private email. I will attach his message privately to the bug report for Joe.
Hmmm, I have that option unchecked already, that’s a shame.
It might be that the xojo framework acts on the WM_SIZING message and limits the size of the window that way i.e. if width < minwidth then set it to minwidth.
If that’s the case then utilising WM_GETMINMAXINFO should fix the problem as it fixes it when that system is used in the code sample above.
I’ll pop that into the ticket for reference.
Indeed that is what Brian thinks : hiking WM_SIZING is why Sizer may interfere with some apps ability to control minWidth and minHeight. He calls that “quite intrusive”, and plans in Version 4 to use less intrusive methods.
I believe Xojo was quite entitled to rely on WM_SIZING as documented by Microsoft, as it was impossible to expect it would become untrustworthy.
In my opinion it is not a Xojo bug, but the result of the actions of Sizer. Now every single message can be hooked, modified and as a result impair Xojo’s aps or other software ability to work as expected. Software interaction is not unlike what happens when someones takes several medications. There are toxic combinations. In this instance, using Sizer impairs Xojo’s ability to control window size.
Xojo supports clean installations of Windows, the way Microsoft intended them, and in 14 years of usage of RB/Xojo to create Windows apps, my programs have always been reliable. I will not lose sleep over Sizer : fortunately, because it is a rather specialized utility, probably not that many people install it by default. Certainly not your average end user. Actually, it was the first time ever I heard about it.
That said, your workaround is a sure way to mitigate the issue. Thank you.
Microsoft wouldn’t implement WM_GETMINMAXINFO if WM_SIZING was meant to be used for min/max tracking, IMHO if it’s done this way then it’s not been implemented correctly in the framework 
Come on… Time out. Break… Use Sizer and be happy.
I exchanged an email with Mitch and he kindly asked if I was happy to make it public. I am so here it is:
[quote]
I’ve looked at the thread and, while I’m not 100% sure what is going on, here are my thoughts:
- You are right to say Sizer has stopped things working.
- When Sizer is configured to “show tooltip when resizing windows” it will attempt to intercept WM_SIZING messages. The approach is quite intrusive and it achieves this by using Windows hooks and subclassing the window being resized. While I have done my best to minimize interfering with other applications, it is impossible to do what Sizer does without causing some side-effects. As you say, it is impossible to envision and manage every edge case. In this case it appears that Sizer is snatching WM_SIZING messages from RealBasic/Xojo apps.
- WM_SIZING messages are not always sent by the operating system. Sizer has special code to detect this situation. From memory this happened on Win9x systems with certain settings. If RealBasic/Xojo is relying on WM_SIZING messages then there may be a bug lurking regardless of whether Sizer is running or not.
-It is not easy (plus I have very limited time) to address this issue in Sizer 3.x. Affected uses can disable Sizer from intercepting WM_SIZING message by unchecking the “show tooltip when resizing windows” option.
-My current priority is to get the new version of Sizer out. Version 4.0 should not cause this issue because it takes a far less intrusive approach.[/quote]
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