Resize Window

[Brian]

I believe there may be a minor software bug in the algorithm that controls the Resize Window instruction.

This sample program, in theory, should open a new window with a width of 401 graphics units and a height of 401 graphics units. In reality, the new window has a width of 383 graphics units and a height of 338 graphics units, so we are short of 18 graphics units on the x-axis and 63 graphics units on the y-axis.

If the new window had been the correct size of 401 graphics units x 401 graphics units, the blue circle would be positioned exactly dead center in the window. If I can be of any further help in investigating or testing this issue please let me know.

Code: Select all

rem Craft BASIC 1.7
title = "Resize Window"
bgcolor 0, 0, 0
cls graphics
resize 0, 0, 401, 401
fgcolor 255, 0, 0
rect 0, 0, 383, 338
fill on
fgcolor 0, 0, 255
oval 195, 195, 11, 11
fgcolor 255, 255, 255
line 200, 0, 200, 338
line 0, 200, 383, 200
end

[admin]

It's more of a limitation than a bug. I'm not exactly sure how to describe it. That's why it's not documented yet.

What OS are you running it on? Windows 95, xp (classic vs xp theme), 10, etc. They all display windows differently. The title bar and the border pixels vary. I have no clue how to detect these changes. So the simple amateur solution is just to make windows bigger to account for the variation. Then test it on all versions and themes to make sure the graphics aren't cut off.

Unfortunately this is an amateur problem. I developed Craft Basic in Emergence Basic. All my games in Emergence Basic have the same thing going on. Take Gem Drop or Marble Puzzle for example. I wish I knew how to resize a window to be the same on all versions of windows. As it is, I have left it up to the programmer to figure out how much extra window space is needed.

Take the snake.run example. You'll see the brown bar at the bottom only displays on certain versions of windows as a filler when the window has extra space.

There's no algorithm behind it. When you use the resize command, it simply calls SETSIZE in Emergence Basic. I tried making some algorithm and decided to leave it as nothing was working on all versions of Windows.

By the way, in your snippet, the title command doesn't use the =. Won't work with it.
Also, you need a wait command after the resize or it won't display the graphics every time you run. It's quirky. Basically you need to call wait when major window changes happen. It also prevents the window from freezing and allows input during loops.

If you know of a cross platform Windows solution in Emergence Basic, please do let me know.
Or in general any and all feedback is helpful and greatly appreciated.

[Brian]

Hello, Gemino. Thank you for the quick and detailed response. I am using both Windows 10 Home and Windows 11 Home operating systems. Both have the same discrepancy count concerning the Resize Window issue. As you say, the quick and easy fix for programmers using Windows 10 and 11 would be to just add 18 to the width count and 63 to the height count to get the correct required Window size.

[admin]

Hello, Gemino. Thank you for the quick and detailed response. I am using both Windows 10 Home and Windows 11 Home operating systems. Both have the same discrepancy count concerning the Resize Window issue. As you say, the quick and easy fix for programmers using Windows 10 and 11 would be to just add 18 to the width count and 63 to the height count to get the correct required Window size.

The hard part is finding the right balance of pixels between 95 to 11. Craft Basic works on all, but if your main concern is 10 and 11 you could just use a size that works for those.
The easiest thjng to do is add extra slace and put a colored border to fill it in. That way the border may ir may not shiw, but at least nothing is cut away.

I was wondering if this would be confusing. I need to document this until a fix is found