Installed Windows 10 on my old laptop. Max Height for a Xojo Window with menu is 729. Even if I set a number bigger than that.
If I try to resize (make smaller) a Window with Min Height > 729 from the top, then the window scroll up as I try to resize down.
The weird thing is that Feedback window look at first start that the height is less than 729 but when I try to resize it gets bigger.
I did some tests, ran the mac version and captured the screen, it looks like the window plus title is 790 pixels.
The issue happens when the Min Height is bigger than the Height available on the laptop screen.
Don’t know if it is only in Windows 10 or maybe in previous versions too.
This is how it looks like when I try to resize the app from top:
That gif made me chuckle Alberto, thanks! 
Probably related to the way the framework handles min sizes, which is incorrect.
<https://xojo.com/issue/43575> from April 2016
I did some tests, in my case, if I set the window Min Height to 730 or higher, I can reproduce this with an app with just a default window.
It looks like Windows 10 don’t let the window start higher than 729, but because I set the Min Height for my default window to 730, then this happens, trying to resize make the window scroll up.
I don’t understand why Feedback app Min Height is set higher than 729 when 600 could show everything (that’s another topic), but thanks to that and my small resolution laptop I found about this.
I will try to test on Windows 7 to see if the same happens.
Tested with Windows 7, the window doesn’t scroll all the way up when I try to resize, it only ‘jumps’ up a little.
My guess is the jump is the difference between Min Height set for Feedback app and 729, the screen height.
Thank you Julian, but that is not it. My ‘little’ jump is like 40 pixels or so. Is hard for me to explain without a video, let me try:
Take the GIF posted as an example, that happens with Windows 10.
With Windows 7, the Feedback app (or my test app with only main window) only ‘jumps’ to almost the same place that you see on the first jump on the GIF, then I can continue scrolling down and the window doesn’t move (as you can see, as I keep going down ‘resizing’ the window it continues scrolling on Windows 10).
Just wanted to know if there was a big difference between Windows 7 and Windows 10 and it exist.
Is easy to reproduce, just create a new blank project, change the Min Height for the default window to a value bigger than screen height, run your app, move the window down a little and try to resize it by selecting the top and dragging down.
Ah ok a different jump 
Ill have a play with it tomorrow.
Curious how tall is the screen ?
I know there used to be some really funky behaviour doing this when the screen was physically smaller than its logical size (ie/ netbooks that had tiny screens that would scorll as you moved the mouse to the top or bottom edges)
The laptop resolution is 1366x768, I guess that with the Window Title and Menu left only 729 pixels.
Running Windows 10, new project, Window1 Min Height to 732, then Run, you can replicate the GIF slowly as you resize down. If Min Height is set higher, then the scroll will be faster.
This is how it behaves under Windows 7:
You can control the ‘jump’ by changing Min Height for the window. Closer to 742 will be small jump, higher value, higher jump.
ah so the actual size of the screen is smaller than the defined resolution ?
so this seems like the issue from way back when - dont recall the bug #
For some reason when you resize a window the xojo framework limits the max size of the window to the size of the default screen (I cant think of a good reason for doing this). This calculation is slightly incorrect (looks like 2 x SM_CYSIZEFRAME). This combined with the incorrect way that the min size limitation is implemented (it changes the window size rather than using WM_GETMINMAXINFO) causes an incorrect calculation near max window size (the size of the main screen). This miss calculation than causes the window position to shift by that miscalculation amount which is what you’re seeing. Or something like that 
Nice bug you’ve found there
Julian, I don’t think this is a Xojo bug but more related as how Windows handle the Window size. That’s why Windows 7 and Windows 10 behave in different way to the same program.
A simple program with Window size 3000x2000 will create and open a Window of that size in macOS 10.12.6 without issue, on Windows it can only be the size of the available screen. I wondered if this was a Xojo limitation so I open Paint on VirtualBox, moved the window and tried to increase the size (width) but then at some point I was not able to increase the width. Then I make the VM window larger, giving the Windows environment a new resolution, then I was able to increase the Paint window width again.
I guess, mac doesn’t care if you open/create a window much larger than the screen, that’s why it works ok there, in fact, mac ‘holds your hand’ by showing if you can reduce the window size or not (if you have Min Width or Min Height) by showing a different pointer icon when you reach the min size, showing only the direction that you can resize the window, windows don’t let you open/create a window larger than the screen that you are using, and there is no change in the pointer to indicate if you reached the min size.
I guess a simple code like this in the window open event:
if me.Height < me.MinHeight Then
// show a warning
quit
else
me.Show
end if
can help.
I think I remember that Windows XP let you have windows bigger than the screen. At least that is what I recall when I used a mini laptop, I think the Height available was 620 or something like that.
Of course I may be wrong.
And of course, Linux is a mix of the two.
Just tested on Linux Mint, trying to open a Window 2200x1900, I get 1165x900 (I guess the value doesn’t count the window title or the menu). Then I can move the window down and to the right, and resize it to make it bigger. It was easy to increase the size to 1674x1295 in a single pull, something that I can’t do with Windows and Paint.
Ah ok, I just did a little more testing. The max window height seems like an OS limitation based on the calculated virtual desktop max height so the height locking mechanism isn’t a xojo thing and I can resize a window larger than the main screen by having another screen to the side that is offset making additional height. I never noticed that.
The issue of the window moving up is definitely a xojo bug, I’ve just tried the same thing in VB.Net and it doesn’t happen performing the same tests.
I don’t have knowledge on other languages to do tests, thank you for checking.
Can you report the bug with Xojo code and VB.Net code for comparison?
Edit: I think is a good idea, that if we limit the Min Height for a Window, at least for Windows 7/8/10, let the user know that the resolution is not supported. Some elements may not show if the width/height is not big enough.
I think the Feedback app has a Min Height set to around 770-790 and the limiting factor is the information displayed when creating a new case.
Maybe the Min Height can be changed a little and make the Steps to Reproduce area smaller. Of course, if we have a bigger screen that area could grow, if not, scrool bar could appear.
Not much point as feedback is apparently being redone on web. It would be nice to fix the root cause though.