Fire "on bound variable change" changing just one property of the container object?

For subforms I usually use an object in the container to inject data.

When the subform includes one listbox (or more), I include the entity selection for the listbox as a property of the object, along with other properties for the subform. I have it pretty standardized.

I’ve found out that «On bound variable change» event is only fired when the whole object variable changes, not if only one property of the object changes.

Is this a design limitation of the objects or can evolve in the future?

I usually asign the value using a pointer to the container, but I also tried it declaring the variable explicitly. Even loading the subform form after the container object is defined.

The main problem are the variables that are being modified inside the subform, like the current entity or current position of the listboxes.

My only workaround is this dirty, dirty trick in 3 steps when I need to update something.

// 1.- Retrieve the current value of the object

// 2.- Change just the desired property

// 3.- Asign again the whole object just to activate the event

Do I need to use the old «Execute in subform»?

I will be really happy if someone tells me a beter strategy.

Thank you in advance:


Yep - that’s the way it works.

What’s the purpose of having the subform change the data in response to outside actions?
If the user changes the data in the subform itself you don’t have a problem. So what is the purpose of the subform? It sounds like it’s some sort of black box that’s acting on the subform data. Perhaps a better solution is to abstract the actions into a method (or class) that receives the object as a parameter. This could be invoked equally from within the subform or the parent form.

You would need to recognize the data change in the parent form but you will need to do that to trigger an update in the subform anyway.

If you must keep the ‘actions’ in the subform I would put the Execute method in subform in the object script of the input object. But I would really take a look at moving whatever the actions are first.

Thank you for your response, Kirk. I forgot one of the main problems. Thats why you feel that something doesn’t fit. :slight_smile:

One of the lisboxes in the subform is made from arrays (just because I need automatic row height).

So I process the selection of entities to make some calculations per row and generate the arrays. This is a method called from inside the subform, and I wanted to activate it from the «on bound variable changed» instead of the Execute in subform or the dirty trick described before.


That makes sense. Personally I would redesign it to work without depending on a form. In principle having business logic bound up with the UI is going to keep causing headaches for you.

Why not separate whatever the business logic into a separate method that manages the data structure (the object) and write a separate method to manage the UI? Yes it’s a little inefficient but it’s also inefficient to support the workarounds you have to employ now.

It is a design optimisation.
Objects can be very long. They can have thousands or even millions of properties. Each can be another object, again with millions of “sub elements”.
If 4D would monitor each “sub elements” every millisecond, global performance would go down extremely and the product would become unusable.

To avoid this, 4D follows every variable - just the top level.
Each widget in 4D subscribes to a variable and follow (trigger event or redraw itself) if this variable change. As said, if the top level change.
If by example a list box display a collection and you directly modify an element inside the collection, the list box will not redraw. If you assign the top element to itself, this triggers a change and this triggers events like a redraw or a “on bound variable change”.

1 Like

Thanks, Kirk. I wanted the array listbox to enjoy the same magic than the entity selection listbox, some kind of unatended update. But, as you say, it will cause many headaches.

Thomas, thank you for the insider view. Even magic has its limits. :slight_smile:


FWIW, assigning the object variable to itself triggers an On bound variable change event in the subform (v18R2).


Hi, Jeremy, nice and useful trick.