Resize Event Not Firing

Is there a reason that re-size does not fire when the size of a control is changed programmatically?

Here is an example project for what I am talking about. The labels in each control represent that control’s width and are updated on resize. Notice the strange behavior of the white box’s width as you make the window smaller than it causing it to scale itself. Also, notice how the button, which resizes the controls, does not have an effect of their reported length.

I have been very deliberate about how each control is locked such that the following is true/expected:

  • Blue rectangle should always remain 200px wide
  • Purple will fill space left by the width of the entire window less the 200 from blue
  • White will center istelf inside purple until purple gets smaller than it and then it will change its own width to remain centered
  • Light blue reflects the width of the entire window

The third point above is thrown completely off when the width of the container is changed by the button

Please take a look and let me know if I am missing something, or what is going on.

Thank you

Example

I believe this is the expected behavior. If you change the size of the WebControl in code, you do not need an event. You already know the size, since you just set it.

If you need things done when size change, you should have a method you can call indifferently from code or from the resized event.

I understand that. But, why (in the example provided) do the controls not respond to the width change then? Th UI changes, but they do not report that their width property has been affected.

It seems to me that because control1 has horizontally locked controls inside it, changing the left property of control2 actually changes its width, but this is not being recorded. Does that seem possible?

The missing resized event is <https://xojo.com/issue/23877>
the wrongly reported size of the inner control likely a variant of <https://xojo.com/issue/30236>

If you combine locking, dynamic and programmatic resizing, there are quite some artefacts to take care of. It seem possible to circumvent them but it is a hassle. I’m hoping for the Web Framework 2.0 to finally clean that up.

Fun: <https://xojo.com/issue/32052> / <https://xojo.com/issue/19727>

Where should it be recorded ?

@Michel Bujardet
They do not report correctly on the labels, nor are the widths reported in the debugger the widths that are drawn. There is a disconnect after the programmatic resize.

@Tobias Bussmann
It seems like the web framework has quite a few issues when you start trying to make dynamic layout. Being able to manage a controls locking at runtime seems like it would solve a lot of issues. Currently, there is much to be desired.

Indeed, these issues are sometimes more painful then necessary. But in the past I was usually able to find workarounds for framework shortcomings if really required.

Not sure, I understand you correctly here. But changing control locks (the .LockLeft property, etc) is not supported at runtime (AFAIR it’s not raising an exception, but clearly neither working nor supported). You need to set the locks either at design time in the IDE or when using dynamic embedding after creation but before you actually embed them to the layout (.EmbedWithin method).