@Admin and @Admin: Cannot be variables

Help & Support
1

Here's what seems to be an interesting gap.

  • I define a global variable UseAdmin with value @admin.
  • I check that value with a button whose only command is {DlgString|UseAdmin = {$Glob:UseAdmin}}
  • I run a second button whose first line is @admin --- it works perfectly.
  • I change the first line to {$Glob:UseAdmin} --- it doesn't run. The error message is:

[Window Title] @admin
[Content] Windows cannot find '@admin'. Make sure you've typed the name correctly, then try again.
[OK]

Or have I misunderstood something? The buttons are standard function (Opus or external)

Similar story if I change the variable to @admin: and insert it on the same line before a command.

By the way, I can easily write a script to work around this, but I thought it was worth reporting.

2

You can't do that, at least not that way.

You could do it using scripting.

But is it really needed? Opus has an admin mode toggle built-in, and when it is on any commands run in the window will be run as admin until it is turned off (either by clicking the toggle again, or by the specified timeout). You'd only need to do something extra if you wanted it to affect multiple Opus windows.

3

Thanks, Leo. So something was wrong with my button commands.

Here's the significant question that I can't answer.

  • I turn on Administrator Mode for 15 minites.
  • I launch some software using a DOpus button, either through a standalone EXE file, or through a LNK file to an installed EXE file.
  • Is that software running in Administrator mode?

The reason for asking, and for my confusion, is:

  • Software that previously required UAC still requires UAC.
  • Software that previously did not require UAC still does not require UAC.
4

If it's launched from the same window that is in Admin Mode, it will be launched as admin.

(There are caveats, e.g. if the software is already running and the new instance you start just tells the old instance to open a new window, then the old instance will still be running in the same context it always was, and the new instance is gone after it sends a message to it.)

An easy way to test is to run cmd.exe since it tells you if it is running as administrator in the titlebar.

5

Thanks, Leo. You gave me the clue about what I was carelessly overlooking:

If it’s launched from the same window that is in Admin Mode, it will be launched as admin.

I had indeed been experimenting with the DOS box (amongst others) because that is very easy, as you say. But I had been elevating using a lister, then launching software through a floating toolbar --- the floating toolbar was, of course, not connected to the lister, so it didn't work.

I now find that when I launch using a button on the same lister, everything works as expected. Also, when you turn on 'Administrator mode' from a button palced on a floating toolbar, software launched by a subsequent instance of the same floating toolbar is not elevated (as one would expect).

So my original problem remains --- I was trying to use a global variable to insert the command modifier @Admin as a first line, or @Admin: in front of the command, an approach that worked perfectly with parameters such as NewTab in other DOpus commands (see my earlier post). Clearly modifiers work differently, which is what surprised me in the beginning.

As I said, no worries. I can script, or even easier, I can use a user-defined command with a conditional that insert @Admin explicitly if the global variable is non-empty.