Bounds - why only Windows?

I just discovered .Bounds for setting the size of a window
Excellent… do it all in one call instead of 4

Hooray!
Now I will apply that to the controls I need to resize…
Nope
Rectcontrols do not have such a property/method - why on earth not?
Again, setting the sizes using up to 4 calls is both inefficient and can cause unwanted drawing to occur.
Why dont rectcontrols have Bounds?

1 Like

No idea but I think is worth creating a Feature Request.

1 Like

What’s a practical use for bounds in a rectcontrol?

mycontrol.left = 20
mycontrol.top = 100
mycontrol.width = 50
mycontrol.height  = 100

//= 4 actions, during which the control may repaint

//versus

Var myrect as new rect
myrect.left = 20
myrect.top = 100
myrect.width = 50
myrect.height  = 100

mycontrol.bounds = myrect   // all 4 parameters set in one call.

It happens faster, especially for a Window, and on ‘Windows’, that is really needed.

I may experiment with SetWindowPos API call, as that seems to allow it

So you changed 4 lines by 5 lines, I keep thinking that’s not a great trade off.

Or

Var myrect as new rect(20, 100, 50, 100)
mycontrol.bounds = myrect

if you prefer one line:

mycontrol.bounds = new rect(20, 100, 50, 100)

of course this doesn’t work until Xojo adds that feature, but you can test with Self.Bounds for your Windows and see that the above code works.

Setting up the myrect doesnt affect the display.
Changing 4 parameters of the control line by line, affects the display 4 times.
Using bounds affects the display once.


mycontrol.bounds = myrect

is what I want but rectcontrols dont have a bounds. Thats where I started. :slight_smile:

I was thinking the same as Jeff a while back and logged case 65579.

In theory, it could reduce the amount of redrawing that the OS has to perform.

This is the example I provided in the case.

I have a control positioned at 500,50 with a size of 150,150 and I want to move it to 0,0

a) MyControl.Left = 0
The OS invalidates the original position / size: 500,50,150,150
The OS invalidates the new position / size: 0,50,150,150

b) MyControl.Top = 0
The OS invalidates the position / size: 0,50,150,150
The OS invalidates the new position / size: 0,0,150,150

At minimum this would invalidate three areas: 500,50,150,150, 0,50,150,150 and
0,0,150,150.

If we had a SetBounds method that called the relevant OS function to update multiple properties in one hit this could potentially be reduced to two areas: 500,50,150,150 and 0,0,150,150.

Reducing the number of areas to invalidate by 1 doesn’t seem like a lot but if there were multiple controls at 0,50,150,150 we could potentially save a lot of unnecessary redrawing which would boost performance.

I see. Less invalidate calls causes a marginal gain, but a gain.
Marginal because changing those properties in sequence should not cause 4 repaints as Jeff said, just one, when the system gets some idle time for repainting and find invalidated controls.

1 Like

Ok so there is a case for this, thank you Kevin:
#65579 - Allow Multiple Control Bounds Properties To Be Changed In One Hit