Button bar: run with elevated privileges (aka admin)

[Thany]

There appears to be no option for a command on the ButtonBar to run with elevated privileges. No official option anyway.

I know of the asterisk. Place an asterisk in front of the command, and it will indeed run with elevated privileges. Except... It doesn't work. `powershell.exe` starts a powershell terminal perfectly fine. But `*powershell.exe` says "File not found".

I'm guessing the asterisk is a hack or an unofficial/undocumented workaround at best, because although there are some mentions of it on the forum, for example, here is one: https://ghisler.ch/board/viewtopic.php?t=29091, but there is no mention of it in the online documentation: https://www.ghisler.ch/wiki/index.php/Buttonbar#Command:

This might be a feature that is not quite ready yet or something, so hopefully it helps to know about this bug.

PS, the [url] tag on this forum is broken: [url=https://www.ghisler.ch/wiki/index.php/Buttonbar#Command:]online documentation[/url]
PPS, the [code] tag also doesn't work at all. Are the styling buttons good for anything?...

[Dalai]

It works as designed and has been for many years. But requires the full path to the file to be specified. Example:

Code: Select all

TOTALCMD#BAR#DATA
*%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

shell32.dll,2
PowerShell as admin


-1

PS: The code and url tags also work fine here, online documentation (as long as the BBcode is not disabled for the post you're composing)

Regards
Dalai

[sqa_wizard]

I'm guessing the asterisk is a hack or an unofficial/undocumented workaround at best ...

It is officially documented at the local help.
Just press the HELP-Button if you modify your buttonbar ...

[Hacker]

Thany,
Uncheck "Disable BBCode" when posting.

HTH
Roman

[Thany]

I didn't see it in the help. But other than that, why can't it be a checkbox?

[Dalai]

But other than that, why can't it be a checkbox?

Well, for one, there's also the possibility to run as a different user via two asterisks:

Code: Select all

**%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe

This is especially useful on systems where UAC is disabled. And seconly, additional GUI controls (like a checkbox) requires translation into the languages TC supports. This has its own set of conditions (translations finished before TC is released etc.).

Regards
Dalai

[Thany]

I'm pretty sure "Run with elevated privileges" or similar is a string that already exists somewhere. Otherwise maybe it can be fetched from Windows.

Also I don't see why translations are able to hold off development. The GUI is awful, sometimes, and translations feel more like an excuse not to have to improve, rather than a genuine cause. I hope Mr Ghisler disagrees with you, and translations follow development, not the other way round.

[Dalai]

I'm pretty sure "Run with elevated privileges" or similar is a string that already exists somewhere.

A button bar button allows both "Run as admin" and "Run as a different user" via one or two asterisks respectively. So you'd need two checkboxes (that can't both be enabled at the same time), or some other GUI controls. Those need translations. The current implementation with one or two asterisks doesn't require translation other than the explanation about them in the TC help.

Otherwise maybe it can be fetched from Windows.

This might work for the Windows versions available at the time of implementation, but as soon as MS changes the string resources in some DLL, or moves them to another one - it's their OS after all - you're screwed and need to change the implementation. Getting things like strings or icons from DLLs can be done for things that have been unchanged for quite some time, but it's definitely not something you can do everywhere or every time.

Also I don't see why translations are able to hold off development.

Simple: Translation takes time. Not all translators are available all the time. And, as author you have to wait for all translators to get back to you before you can release a new version of your software. The more languages a software supports the longer it can take. It's not the development directly but the release that's being delayed by new and/or updated translations. Now you might think "why not release the software and add the translation(s) later?". As author you want to make sure that all text is translated, preferably properly. Otherwise users might get the impression the author doesn't care.

I hope Mr Ghisler disagrees with you [...]

He's the one that brought up this point on multiple occasions. As an author of multiple plugins I can understand this argument quite well.

[...] and translations follow development, not the other way round.

Oh, they do. But a software developer needs to think carefully about every GUI decision as soon as translations are involved. It's GUI control placement, length/width, and many more. Even cultural things might play a role.

In the end, it's a balancing act. Either you add GUI controls and wait for the translations, or you do without them and find some other way to make a feature work. In this case it's the latter.

Regards
Dalai

[Thany]

A button bar button allows both "Run as admin" and "Run as a different user" via one or two asterisks respectively. So you'd need two checkboxes (that can't both be enabled at the same time), or some other GUI controls. Those need translations. The current implementation with one or two asterisks doesn't require translation other than the explanation about them in the TC help.

This is a terrible excuse to implement features obscurely. Burying it in the documentation does not un-obscure it.
It's fine if you don't want to add translations, but if this means to reduce the discoverability of a feature to nearly 0, it has become an antipattern, iyam.

Simple: Translation takes time. Not all translators are available all the time.

That just means you start with the translations, instead of finishing up with em.

But a software developer needs to think carefully about every GUI decision as soon as translations are involved. It's GUI control placement, length/width, and many more. Even cultural things might play a role.

That's the role of a UX designer, not a developer ;) but TC is a one-man show and UX is not a priority, clearly :)

Anyway, I really don't think we should be making a mosquito into an elephant here (that's a Dutch proverb, I'm sure you can imagine what it means). It's just a bloody checkbox. Maybe two.