Gadgets are now clipped to their parent’s dimensions.
(Cue round of applause and champagne corks.)
This was incredibly difficult to implement. First of all, I needed to write a routine that would return a clipped rect - if the x value of the gadget is less than the x value of the parent, use the parent x, and if the gadget’s (x + width) is greater than the parent’s (x + width), set the width of the rect to the difference between the two.
Once I’d got this, I could amend the visible rect caching function to use the clipped rect’s dimensions instead of the gadget’s. After that, I could amend the rectangle splitting function to use the same routine. The collision detection routines needed to be updated, too.
Doesn’t sound to difficult. In truth, it wasn’t. None of it worked, though, which was the problem. There seemed to be something very strange happening with the screen class - all of its children drew themselves OK, but the screen refused to co-operate. It just wouldn’t draw itself at all. Memory leak? Another deleted pointer? Maths problems? I went through everything over and over again, but couldn’t find anything wrong.
In the end, I modified the Debug class to output a non-transparent background so that I could see what it was writing out, and started printing values to the screen. Seems the Woopsi instance was reporting its width as 0 - aha! The clipping routine only goes up one level, so if the screen says it is 256 pixels wide, all gadgets will work on the assumption that they have 256 pixels to play with. When the screen tries to draw itself, though, it clips to Woopsi’s width of 0 pixels and nothing gets drawn.
It turns out that I’d got the parameters in the call to the base Gadget class the wrong way around in Woopsi’s constructor. Fignuts.
Other things I’ve fixed include marking the WindowDepthButton as a decoration, making a minor improvement to the Gadget::getClientRect function (missed out some pointless re-calculation of values), removing Woopsi::removeOverlappedRects (as it did exactly the same thing as the version in the base class), and re-writing the Gadget::eraseGadget function. This now handles gadget erasing using the gadget’s own visible rect cache, instead of bubbling the request up to the Woopsi instance and allowing that to send the redraw request back down through the hierarchy. As part of all of these changes, I’ve fiddled around with various functions that either invalidate the rect cache or call the cache function.
Hopefully I haven’t broken anything, but there’s a lot of fiddly changes here.
Pressing the “A” button in the latest SVN demo will cause the uppermost bitmap button tp move one pixel to the right. If everything has gone to plan, it gradually disappears into the edge of the containing window.
This should lay the groundwork for exciting new things such as scrolling panels (think SuperBitmap-style scrolling, but with scrollbars, that can have developer-defined “allowHorizontalScroll”, “allowVerticalScroll”, “maxHorizontalScroll” and “maxVerticalScroll” values, and that can contain child gadgets). If that works as I hope, I should be able to put together my AmigaGuide interface (scrolling text panel interspersed with buttons) without any real effort. (Aside from, y’know, making the gadgets and everything in the first place.)