[BUG] Moving Button Pages Breaks Links To Buttons On Changed Page

[jsnyder886]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Moving a page to a new location breaks the links to all of the buttons that were linked to the page and any other pages that were reassigned as a result of that move. That is to say the references from other pages and triggers do not follow to the new page number assignments. The same behavior is true if you delete pages or insert new pages; any references throughout companion to any page numbers higher than the pages that were deleted/inserted will be incorrectly pointing to whatever page fell into place at the referenced location.

Steps To Reproduce

Assign a trigger to do a button press with assignment 10/0/0

Buttons Tab
Pages sub-tab
Move page 10 to page 6
Check your trigger, it still says 10/0/0 and whatever page fell into place for page 10 will be what the trigger fires.

Expected Behavior

All references for button presses, feedback duplication, etc. should follow the page to it's new location assignment.

Environment (please complete the following information)

- OS:  Windows 11 23H2 Build 22632.4460
- Browser:  Chrome 131.0.6778.109 (Official Build) (64-bit)
- Companion Version: 3.5.0+7611-main-2a20551a

Additional context

No response

[dnmeid]

I wouldn't say that this is a bug, it is just the normal behavior. If you reference page 10, then you reference page 10 by its number. It is the same with a button. If you reference location 1/2/3 and move that button to location 1/2/4, the trigger will not be updated. It actually has to stay that number and I'd consider everything else wrong.
What we can consider though is a new type of reference to a page, e.g. reference by name.
Then you could write a location maybe like "My moving page"/0/1 and it would always trigger at "My moving page".

[jsnyder886]

If the page number assignment was used as the unique key for the page, I would be able to get behind the idea that the current state is the correct behavior as opposed to a bug. However, given that the page order can be moved at all, that would seem to lend itself to the notion that the page number is in fact not a unique identifier for all of the references within that page.

What's yo8ur suggesting by creating the ability to reference the page by its name that would then follow it to whatever order it is ultimately positioned in seems like an unnecessary extra step. Obviously I'd be grateful for a solution in whatever form it comes in, just my thoughts though.

Cheers!

[Julusian]

This is a tricky one to think about, as there are differing opinions on what the 'default' behaviour should be.
I can understand the arguments both ways, but I am personally leaning more towards not fixing up any references in the current syntax/actions because we can't reliably handle all the cases and it is going to cause confusion frustration either way.

For example:

• If a button is referencing $(custom:abc)/1/1 we can't fix that
• If you import to page 2 which references page 99, add a page 3, then re-do that import to that page your two pages will be identical except for which page they reference will get a different result. This may or may not be desirable depending on context.
• Anyone making calls into the http/osc/etc apis can't be automatically fixed
• In some cases, users will want the references to not be updated.

Also, not touching the page number is consistent with how we don't and have never updated any references to a button as it gets moved around the page.
Until we had this page moving ability, I know that people would workaround the limitation by exporting and reimporting a page, so are used to this lack of updating.

So to me, not updating the references is predictable and consistent with other things. But I do see value in there being either an alternate action, or an option, or some other way to tell companion that one of these is 'pinned' to a particular page, and not a page number.
This has been on my todo list since adding the ability to move pages, but I simply haven't gotten around to it. And there is a question on how should it follow the page, should it be that we fix up the number, or should we use page names, or maybe the internal page id? Each has varying benefits and tradeoffs in ability/durability/complexity
Another option to consider, is maybe it should be possible to have 'relative' references, to be able to always reference the 'next' page or '3 pages after this one' and that kind of thing. Not sure if it helps here at all, but could be a nice future extension