Currently there is a command OPENBAR which accepts a path to a bar file as a parameter. It allows to switch to another bar in a user command (unlike the button, usercommand cannot switch to another bar by setting just a path to a bar file).
To make it possible to assign the "show bar as menu" action to the em_ command, I suggest to add also a new command SHOWBARASMENU with <path_to_bar_filename> as a parameter.
A command to show the bar as menu
Moderators: white, Hacker, petermad, Stefan2
A command to show the bar as menu
Donate for Ukraine to help stop Russian invasion!
Ukraine's National Bank special bank account:
UA843000010000000047330992708
Ukraine's National Bank special bank account:
UA843000010000000047330992708
Also (or alternatively) TC may just use the iconic parameter also for user commands. If the parameter iconic doesn't exist TC can behave like it does currently: try to launch the bar file with the asscoiated porgram.
Donate for Ukraine to help stop Russian invasion!
Ukraine's National Bank special bank account:
UA843000010000000047330992708
Ukraine's National Bank special bank account:
UA843000010000000047330992708
I looked at bit as this and the current implementation looks quite strange to me.
Whenever you select a bar file as command in a user command the option 'show bar as menu' is available. So in this case it behaves as if the user command is actually a button. However when used on a button this command actually executes the file with the associated app (as expected). So I guess removing the option in this case would make sense.
It's even discussable if the current behavior on buttons is meaningful. How do I edit BAR files with my favorite BAR files editor?
So it seems it makes sense to support this little suggestion as it would also allow opening menus from just about everywhere...
Where to open menus opened using a shortcut/alias you ask? Same place where history and directory menus are opened.
Whenever you select a bar file as command in a user command the option 'show bar as menu' is available. So in this case it behaves as if the user command is actually a button. However when used on a button this command actually executes the file with the associated app (as expected). So I guess removing the option in this case would make sense.
It's even discussable if the current behavior on buttons is meaningful. How do I edit BAR files with my favorite BAR files editor?
So it seems it makes sense to support this little suggestion as it would also allow opening menus from just about everywhere...
Where to open menus opened using a shortcut/alias you ask? Same place where history and directory menus are opened.