Button numbers changing when dragging in Config>Events>Buttons

[hermetheuscoffee]

In Config>Events>Buttons, it's possible to drag and drop buttons to control the placement of them. However, I've seen two different behaviors for the numbering of those buttons. Currently, when I drag and drop, the button number gets CHANGED so that the list of buttons is always in ascending order from 1 to n.
However, I'm CONFIDENT that I've seen other cases where the button number is retained, even after dragging.
What determines if a button gets re-numbered? In my case, I use the "Multiple Events" command on "Drop", so it's important that the button numbers stay the same, even if buttons get moved around or new buttons are added. Is there a way to achieve this?

[MAKOMO]

By drag-and-drop you only change the visual order of the buttons in Artisan v2.8.2 which is in turn used to reorder the internal button list accordingly on establishing the updated button list.

As this is can be confusing during editing, especially on using the insert action after several drag-and-drops, this behavior has just been changed. The (visual) row numbers are updated now directly after a drag-and-drop and are thus kept always in order and the internal model is immediately updated.

Anyhow, references to buttons is always by position (a 2 is pointing to the second button in the list) and if the order of buttons changes without adjusting the reference accordingly, it can point to a different button after a drag-and-drop action. There is also no easy way to have Artisan to automatically adjust all references after a drag-and-drop as button references can even result from a calculation. Further, on switching palettes (of buttons) button positions referred to for example from a DROP command action might not even exist any longer. Thus even introducing stable (unique) button IDs which are independent from button positions would not resolve this issue.

[hermetheuscoffee]

This is such a helpful answer... thank you, Marko! I was using the continuous build when I noticed the changed behavior. I didn't realize that references to buttons were always by row position, so this is incredibly useful info!
I can also see the complexity of trying to address this, especially when palettes are involved (which I also utilize).

For anyone like me who wants the ability to address Multiple Events (by number), yet allow another roaster to re-order the buttons without breaking things, here's a simple solution:

1. Create ALL of your commands that will be addressed by buttons at the very top of your list of buttons. For instance, if you have 5 commands you'll want to address, make those buttons the first 5 buttons, and turn their visibility to "OFF". This way, they won't be seen in the UI as a button.
2. Add some very clear descriptor in the "Description" field not to move or delete these buttons.
3. Now at this point, create another VISIBLE button that references one (or more) of the first 5 buttons in the list. The user is now free to drag and move this visible button, but the reference to the command won't change.
   Something along the lines of this:

[roasterdave]

Excellent suggestion!
Thanks @hermetheuscoffee

[darrenaddy]

Sounds like this might be a good subject for a video, Jason! ;)

…

On Thu, May 11, 2023 at 9:25 AM hermetheuscoffee ***@***.***> wrote: This is such a helpful answer... thank you, Marko! I was using the continuous build when I noticed the changed behavior. I didn't realize that references to buttons were always by row position, so this is incredibly useful info! I can also see the complexity of trying to address this, especially when palettes are involved (which I also utilize). For anyone like me who wants the ability to address Multiple Events (by number), yet allow another roaster to re-order the buttons without breaking things, here's a simple solution: 1. Create ALL of your commands that will be addressed by buttons at the very top of your list of buttons. For instance, if you have 5 commands you'll want to address, make those buttons the first 5 buttons, and turn their visibility to "OFF". This way, they won't be seen in the UI as a button. 2. Add some very clear descriptor in the "Description" field not to move or delete these buttons. 3. Now at this point, create another VISIBLE button that references one (or more) of the first 5 buttons in the list. The user is now free to drag and move this visible button, but the reference to the command won't change. Something along the lines of this: [image: artisan_button_trick] <https://user-images.githubusercontent.com/95500043/237718257-850db5c3-5c0e-44fc-8e9f-c3da62a8f9c5.jpg> — Reply to this email directly, view it on GitHub <#1161 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO5YMLRKNPEYH5QCDR2XJL3XFTZFVANCNFSM6AAAAAAX3ZHNSY> . You are receiving this because you are subscribed to this thread.Message ID: <artisan-roaster-scope/artisan/repo-discussions/1161/comments/5873973@ github.com>

[MAKOMO]

Dear Jason, Dear Darren,

we just uploaded a (signed) beta release of the next Artisan version.

https://github.com/artisan-roaster-scope/artisan/releases/tag/v2.8.3-beta

This one features only a few minor new features, but many bug fixes (see Release History). We extended our tool chain with additional static checkers which help us to quickly detect certain type of bugs automatically without any testing. To get this going we needed to touch almost every line of code and might have introduced some unintended negative side effects (bugs). As we want the next Artisan release to run as stable as possible for all users we ask you, identified Artisan experts, to test this beta version and report back any findings via the regular GitHub bug tracker.

We plan to run also a second test phase announced to the wider community using a Release Candidate build afterwards.

We count on you;)
Marko & Dave

PS: one of those new features is an extension of the button item drag-and-drop action: if the user holds the ALT (Windows) or OPTION (macOS) key the dragged button is swapped with the destination button, instead of just moved.