Hyperion Entertainment Message Boards

Currently, if you try to open a window that neither defines a layout, nor specifies any dimensions, you'll get a system freeze because the window imagery apparently won't fit in the zero-size window. Could Intuition and/or Window Class possibly implement a safety check to prevent such a situation?

Are you sure that it's freezing for that reason?

I haven't tried to duplicate your invalid call, but I do remember years ago opening zero-size windows and ending up with just a Close box on the screen. I was able to close it and recover, though.

Edit : post deleted. sorry to be entered in your discussion, Trixie...

@tonyw

I haven't tried to duplicate your invalid call

I'm doing
and then execute WM_OPEN upon the successfully created object, which is hardly an invalid call. The window opens fine if I specify WA_InnerWidth and WA_InnerHeight with some meaningful values.

Now it came to me that I haven't updated intuition.library because my loaner machine is not connected to the net. So perhaps the freeze has been fixed post-Update 6? Sorry for a false alarm if it has.

trixie wrote:@tonyw

I haven't tried to duplicate your invalid call

I'm doing

Code: Select all

and then execute WM_OPEN upon the successfully created object, which is hardly an invalid call. The window opens fine if I specify WA_InnerWidth and WA_InnerHeight with some meaningful values.

Now it came to me that I haven't updated intuition.library because my loaner machine is not connected to the net. So perhaps the freeze has been fixed post-Update 6? Sorry for a false alarm if it has.

I don't think it has yet and I've noticed this too when I tried to learn to code using ReAction. I have all available updates installed. I tried out all kinds of things, among which opening a window without WA_Width and WA_Height and without any layout yet. For quite some time I could not figure out why the OS froze because I could not find out what was wrong. So I agree with you. I think that either the window should open or creating the window object should fail, but preferably the former.

On the subject of windows sizes, it used to be so that resizing a normal window to almost nothing caused some sort of imagery to the right of the window and resizing it even smaller caused a system freeze. After testing it just now, that appears to have been fixed, so that's nice. I can resize a window to 1x1, which creates a new problem because I can't resize it bigger again, maybe because of the rounded corners. (Just thought that was funny to notice, I don't consider that a flaw of the OS or else a real problem).

Trixie, does it behave the same (lockup) if you specify H/W values of zero, or is it only when no values are specified?

Does it just freeze or is there some crash output?

@tonyw

tonyw wrote:Trixie, does it behave the same (lockup) if you specify H/W values of zero, or is it only when no values are specified?

No window size tags specified ==> freeze
WA_InnerWidth, 0 / WA_InnerHeight, 0 ==> freeze
WA_Width, 0 / WA_Height, 0 ==> freeze

This is a layoutless Window Class-based window. In all cases no crash output on the Reaper or Sashimi. The window appears as a small grey vertical bar in the middle of the screen (see attached picture) and a complete system freeze follows. This is on a composited Workbench screen. Behaves a little differently with Compositing Effects switched OFF (the vertical bar is not grey but contains window border graphics) but freezes in the same way as with the composited screen.

As a work-around, have you tried including :

WA_MinHeight, 50,
WA_MinWidth, 50,

or some such?

Be aware that the MinWidth/MinHeight are an absolute minimum and the window can never be reduced below those values until they are changed again in the Object.

I use a minimum width of about 150 (give or take).

@tonyw

As a work-around, have you tried including ...

This is not the point, Tony - I have been using workarounds like this for years. The point is that the safety check should IMHO been implemented in Window Class. That is, if the programmer passes a window without a layout and with no size specified, the class should enforce some minimum values to prevent the lockup. This is what I'm currently doing in my Application Class: every window added to the class is checked for size and if needed, the class applies the safety measure. But this is a workaround as well: the problem pertains to windows so it should be dealt with on the Window Class level.

There are two schools of thought here, though: one is that the programmer (and the OS) should be protected against all input that causes bad results (I say it that way rather then "invalid input"). This means testing for null pointers, zero sizes, etc, etc. There is an infinity of potential "bad" calls to the OS, as you know, and only a few can be tested in a reasonable time-frame.

The other extreme is to test nothing, but depend on the caller having some "nous". That used to be the norm in the C64 days and the early Amiga days, although thankfully we are adding some basic tests to the OS as it matures.

I fully agree with your concerns, but I fear that adding such tests will not be taken as a high-priority task. I'll write a BZ for it once I have generated a test case. We must have a test case (just a program that opens a window and freezes the OS is fine).

(edit) I have created a test case, if you give me an email address, I'll send you a copy of the source.
The bug report is now submitted as #8726.
(/edit)