Make sure you're on the latest stable or beta build
Is this a bug in companion itself or a module?
Is there an existing issue for this?
Describe the bug
This is followup to #4065, discovered while implementing an optimization to that scheme.
If you specify isInverted while referring to $(this:column) or other location-related variables, moving a button around will cause the isInverted computed value to be updated. I believe this is because of a control.triggerLocationHasChanged() call in the controls tRPC router for moveControl or swapControl, and its implementation through ButtonControlBase.triggerLocationHasChanged will perform this.entities.resubscribeEntities(EntityModelType.Feedback, 'internal').
But if you specify storeResult while referring to $(this:column) or other location-related variables -- for example, by specifying a location of $(this:page)/$(this:row)/$(this:column):
and then you move a button containing such action around, nothing in particular causes the storeResult value to be recalculated. (Obviously, resubscribing internal feedbacks won't affect any actions!) And so it will remain stale, computing the old value. And in the above case, the store will fail because the local variable won't exist on the old button (unless the user recreates it).
Steps To Reproduce
No response
Expected Behavior
ButtonControlBase.triggerLocationHasChanged needs to trigger recalculation of any storeResult information, on entity move, if any storeResult info depends on location-related variables.
This presumably could be done by adding this.entities.resubscribeEntities(EntityModelType.Action), but that's going to entail double-looping over all entities and avoidable extra work. Maybe the onlyType/onlyConnectionId scheme ought be converted to a user-supplied function filter mechanism instead?
Environment (please complete the following information)
Additional context
No response
Make sure you're on the latest stable or beta build
Is this a bug in companion itself or a module?
Is there an existing issue for this?
Describe the bug
This is followup to #4065, discovered while implementing an optimization to that scheme.
If you specify
isInvertedwhile referring to$(this:column)or other location-related variables, moving a button around will cause theisInvertedcomputed value to be updated. I believe this is because of acontrol.triggerLocationHasChanged()call in the controls tRPC router formoveControlorswapControl, and its implementation throughButtonControlBase.triggerLocationHasChangedwill performthis.entities.resubscribeEntities(EntityModelType.Feedback, 'internal').But if you specify
storeResultwhile referring to$(this:column)or other location-related variables -- for example, by specifying a location of$(this:page)/$(this:row)/$(this:column):and then you move a button containing such action around, nothing in particular causes the
storeResultvalue to be recalculated. (Obviously, resubscribing internal feedbacks won't affect any actions!) And so it will remain stale, computing the old value. And in the above case, the store will fail because the local variable won't exist on the old button (unless the user recreates it).Steps To Reproduce
No response
Expected Behavior
ButtonControlBase.triggerLocationHasChangedneeds to trigger recalculation of anystoreResultinformation, on entity move, if anystoreResultinfo depends on location-related variables.This presumably could be done by adding
this.entities.resubscribeEntities(EntityModelType.Action), but that's going to entail double-looping over all entities and avoidable extra work. Maybe theonlyType/onlyConnectionIdscheme ought be converted to a user-supplied function filter mechanism instead?Environment (please complete the following information)
Additional context
No response