I've put this in Reaction forum but it would equaly apply to Intuition I suppose.
Since quite some time AmigaOS4 windows resize with their contents by default. This is completely fine if you have a window that only contains gadgets and all those gadgets are laid out by the containing layout gadgets.
However if you are rendering your own content, when you respond to a IDCMP_NEWSIZE event by rerendering your content to suit the new window size, it's very easy to get caught out and render over the window borders, because whilst you were making you calculations, the window changed size again! You usually that happens when the user is reducing the winsdow in size quickly.
I first came across this with AWeb and fixed that by simply avoiding the problem and switching off resizing with content for AWeb windows (overiding the user preference)
I also have the problem in SketchBlock, and as the contents in SketchBlock render relatively slowly (if you have a large project anyway) the effect is very noticable. I've solved it in sketchblock by coding a specific "sketchgadget" which is a subclass of the space gadget and handles any rerendering on window size changes, but it's complex and I'm not happy that it;s the best solution.
I'm experiencing it in new app where I need to "manually layout" a bitmap image, the source of which might be quite large so it's slow to scale and will overwrite the window when I redice it in size moderatly quickly.
So how then do you avoid this issue in the "correct manner" and retain resize with content?
Try using WFLG_GIMMEZEROZERO, as thiswill set up a clipping region in the usable window space, and stop anything rendering over the borders.
Simon
Ah, brilliant that does exactly what I need!
Thanks
@broadblues
Something to keep in mind with using GZZ is that it probably uses almost twice as much video memory if layer compositing is enabled or smart refresh method is used as it creates two layers, one for the borders and another one for the window contents.
Why not just call RefreshWindowFrame() after drawing into the window? That at least guarantees that the window border is correct. The autodocs even say "The expected use of this is to correct unavoidable corruption"...
Author of the PortablE programming language.
I love using Amiga OS4.1 on my X1000 & Sam440 :-D