I’ve implemented Width on a custom canvas and I can intercept a button’s call to set width before it actually takes place, however this doesn’t happen when the window is resized and the canvas is locked to retain its right edge.
Does anyone know why this might not be happening, what Method design I might need to use to intercept this or if this is a bug/oversight?
Here’s a little demo showing the problem, if you click the button you can see the debug output, but if you drag the right edge of the window you don’t even though the width is changing.
PS. I know I can find out the width during a paint, but this isn’t what I want to do
I ran into the same kind of limitation in RubberViews, and various custom classes. The only solution I found was to use a timer to monitor with and height every 500 ms or so.
Hit the same problem back in 2017 and logged the following enhancement:
We only had this problem in a couple of places so we took the simple approach and added code to the Window Resizing / Resized events that called a method on the relevant controls telling them to update their internal state.
Width isn’t a method on a canvas
Its a property
So the width method on the subclass doesn’t “override” the property - the framework wont use it instead of the property (and yes it can tell the difference getween a method and a property)
And, sadly, if you happen to shadow the property sort of “correctly” the framework still doesnt use the get/set pair for the control when you drag the window larger
Would be nice if it did
And this precisely what Kevins report is about
Thanks all, it’s a real shame it uses a separate code path in this situation, lets hope it’s an “easy” implementation on <https://xojo.com/issue/50397>
it would make shadowing much more effective and making subclasses of built in controls much more useful since you could insert code into the getter / setter of properties
I think 50397 should be a bug report not an FR
FWIW you COULD observe the frame property of the control using declares on mac and implement a windowProc to watch for WM_SIZE on windows and also connect to the configure-event on linux… not a trivial effort, but if it’s absolutely needed, it’s not as bad as it sounds… it is doable.
just that it should not be necessary IF the framework set the instance’ properties like you might expect its doing to achieve locking
and if the framework did that for every property shadowing becomes quite useful - not just sizing ones
Since controls in Windows inherit properties, events and methods from Window, it should be possible with declares to attach to Canvas an event handler for resized or resizing.
I’m wildly guessing here, but my understanding is that because Width, LockXYZ (et al) are properties of RectControl, not of Canvas (or your subclass/instance) the Framework likely implements Locking and Resizing in a general way on that (or Window) level maintaining the Widths of all Controls cast as RectControls. That is exactly where Shadowing falls short…
Quite possibly but the framework should be setting the INSTANCE’ property not reaching under the hood to set RectControl’s property
If it did things that way this gotcha with shadowing would simply not exist
And it would mean that ALL properties (that are actually properties not method pairs) would just work when shadowed “properly”