internal: press (& release) - Button Names

[Fred-DTV]

Describe the feature The dropdown for pages already shows the corresponding page names It would be great if the button dropdown list could show the button titles too.

Usecases Would make it a lot faster to create linked buttons, because there wouldn't be a need to scroll through the pages before to look for the right button

[istnv]

(This should be in the 'bitfocus-companion' (internal) module) This is not a simple feature as the button 'names' include dynamic text. Would you want the text $(var:name) displayed or the value?

[Fred-DTV]

Not sure if i understand you right, but I think just the plain text that is written in the "button text" field would be ideal. If the button name is a variable it could just be the current value or even the variable itself e.g. "Button 1 ( $(internal:time_hm) )" could also just be: "Button 1 ( 20:02 )"

[istnv]

This one is not that easy. Unlike the 99 pages, there are effectively 3168 buttons. The dropdown options are not automatically updated when you change an option. They are created when you select an action with page/button options. While it could display 'this' page of buttons, when you select a different page, it would not update the button selection to the labels on the new page.

[Bambii556]

This would be a great feature as i already have a 'Action' page with buttons linked to a action and those gets triggers from my other page's buttons. Would it not be possible to just update the button list every time the page selection changes and then defaults the selected button to the first one or just a unselected state.

[Julusian]

With recent changes to make the internal module use special dropdown types internal:bank this is a lot more doable.

But it does still need some thought on how to get the names needed into the ui without introducing more performance issues

[Julusian]

Is this necessary in conjunction with #2102 ?

[Fred-DTV]

for the workflow of finding the right button it still would be quicker to see all the button names in the list, but #2102 is a good solution for now :)

[dnmeid]

I want to add here that I doubt the concept of calling buttons by position at all. I the vast majority of the cases users want to call a button because of its functionality and not of its position. Any logic built around call by position will break if you move the button. So this is an inferior concept. I've made a proposal (#2387) where I suggest to separate the actions and logic of the button from the button itself. All the logic would be a stack or script or whatever you want to call it and this would be usable in more than one button. It would also be callable from other stacks or triggers thus totally eliminating the need for call by position. And also eliminating the need of creating bogus buttons just for the sake of beein called from somewhere. For this request it means, when I want to call a button by position, then the position is the only relevant information and not the content of the button at that time.