I am using this code to create a custom window.
windowObject = WindowObject, WA_ScreenTitle, "Spotless", WA_Title, "Spotless", WA_SizeGadget, TRUE, WA_DragBar, TRUE, WA_CloseGadget, TRUE, WA_Activate, TRUE, // WA_DepthGadget, TRUE, //This line crashes the program /* WINDOW_ParentLayout, HLayoutObject, //These lines make it work again LAYOUT_AddChild, ListBrowserObject, ListBrowserEnd, EndHGroup, */ EndWindow; if (windowObject) { _windowPointer = (struct Window *) RA_OpenWindow (windowObject); }
And I am using this (preliminary) code to control it.
bool close = false; while (!close) { uint32 result = IExec->Wait (windowSignalMask() | SIGBREAKF_CTRL_C); if (result & SIGBREAKF_CTRL_C) { close = true; } bool done = false; while(!done) { uint32 Class; uint16 Code; Class = IIntuition->IDoMethod (windowObject, WM_HANDLEINPUT, &Code); if(Class == WMHI_LASTMSG) { done = true; } else { switch (Class & WMHI_CLASSMASK) { case WMHI_CLOSEWINDOW: close = true; break; } } } } closeWindow ();
Adding the depth gadget makes the application crash as soon as you try to resize the window. Adding content, that increases the initial size of the window makes it "safe" again. This code should be fairly standard, no mysterious entities.
This irritates me quite a bit, because I would like to be able to generate dynamically modifiable windows, that initially have only generic attributes. Can anyone confirm, that this is a real issue?
EDIT: Maybe this issue is triggered by the windowing theme. When resetting theme to default in GUI prefs, the crash does not occur.
EDIT EDIT: The issue still remains though with the customized window frames setting on.
AS a general rule you should avoid making a window smaller than it's contents, including it's border gadgets. Things get un predicatable if you do that, in a perfect world all gadgets would play absolutely safe, but the world isn't perfect. Windowe class handles making the window big enough to hold it's top layout, but doesn't to my knowledge take any account of the system gadgets. If open an intuition window directly you always need to deal with this.
There is no reason to open a 'zero sized' window anyway, but should you really need to make it border and gadgetless!
Ok, that makes somewhat sense. I still am a little baffled by the fact, that what counts as the most generic case of window opening (the system call with the least amount of non-default parameters) actually leads to a system meltdown. For me that counts as a brainfart.
@alfkil
For efficiancies sake, Amiga OS (whichever flavour) general does very little error checking, relying on the develeoper to follow *all* the needed steps, this may seem old fashioned, but hey it's a retro OS :-)
Retro or not, it still counts to me as a case of lacking the least amount of testing. I don't see the point in not fixing it. Unless, of course, that some kind of backwards compatibility requires it to crash. ;)