What am I missing. In my container control resizing event I am resizing some other controls on the window in which the container control resides. The event is not firing. I have even put a msgbox within the resizing event to see if it is firing but its not. Whats going wrong here?
Are you dynamically adding the container or putting it in at design time? If at design time, make sure it’s lock properties are set and if dynamically you will need to set those properties after creation but before embedding.
This is not right. It appears the Resizing event only occurs if the container is locked to the window. If I programatically change the width of the container the resizing event does not occur? Why not?
Because programmatically changing the width isn’t a user driven event?
It’s worthy of a Feedback report if nothing else. It sounds like a framework bug or, at the very least, a missing element in the framework.
Well the way I am using it is I have a canvas 5 pixels wide in the container being used as a splitter. When this is dragged I use the x offset to resize the canvas so as I am dragging the canvas and the container is changing size I would expect the resizing event to fire.
I have worked around this now by having an event definition called SplitterChanged in my container. The in the Resized event of the container just RaiseEvent SplitterChanged. This then gives me the desired event when the container is resized programatically.
I’m not sure whether to file this as a bug or not can anyone advise.
Lock a container control to a window on all 4 sides.
Run and change the size of the window by dragging its edges, the container controls resizing event fires
Put a button on the window in its action set the window size to 800.
Run again, click the button so the window and container resize to 800.
The resizing event does not fire.
Is this a bug? When does the resizing event occur? For example my next test I put various sizes in the button action event i.e.
self.Width = 800
self.Width = 600
self.Width = 700
So is the window now resizing from 800 to 600 to 700. I believe so but the container control Resizing event does not fire even though it is changing size with the window.
Why not use the Paint event for that?
For what? Resizing a control???
Thats the type of thing which would cause window flicker on Windows. Imagine in my paint event I am carrying out all my graphics processing on my control then carry out a load of resizing of controls and because of doing that the paint event re-fires so I then do all my graphics processing again which then raises another resize event which causes the controls to resize raising another paint event… and so on… and so on…
The Paint event is called during a resize of a ContainerControl. Do your calculation in there.
I’ve always done it that way and never had any problem (incl. Windows).
I try and only carry out graphics and drawing related items in my paint event. I think people should be more aware of doing too much in a paint event. Events like paint are fired so regularly that you can easily consume a lot of resource by bogging down your paint event with too many operations.
You may have a powerful machine. I have but think of end users who may not.
You can use flags to detect a resize and prevent too frequent execution.
Well I have a ContainerControl subclass and the first step in the Paint event is a check if the Width or Height property has changed and if yes, it calls the Resizing event (which is - as we know - not called automatically) and then the Paint event is raised. With that I have a working Resize event and it is only called when the size has changed. Works very well - on a 2008 iMac with 3 GB RAM and on a Sony VAIO from 2003 (my oldest two test computers).
Fair comment. So to answer my OP the resizing event does have a bug?
I don’t know if it is really a bug - I always thought that it made sense that only the window had Resizing/Resized events. Everything can be done in these two events. That’s also the reason why RectControl and its subclasses don’t have these events.
The one and only problem is that if you want to have a ContainerControl subclass reacting to these two events, you are trapped. And that’s where using the Paint event is the solution.
[quote=71979:@Eli Ott]I don’t know if it is really a bug - I always thought that it made sense that only the window had Resizing/Resized events. Everything can be done in these two events. That’s also the reason why RectControl and its subclasses don’t have these events.
The one and only problem is that if you want to have a ContainerControl subclass reacting to these two events, you are trapped. And that’s where using the Paint event is the solution.[/quote]
Ok thanks