FileCreateShortcut with Environment Variables

[woffi]

Hi!

I'm working on a little tool to create WIndows shortcuts, obviously using FileCreateShortcut to do so. Everything works like a charm - except when I specify something like "%logonserver%\share\program.exe" as the shortcut target, the actual contents auf the environment variable %logonserver% is written to the shortcut, whereas I would literally like %logonserver% in there.

Curiously, this only seems to happen in the target-field of the shortcut. If I use something like %logonserver%\share as working-dir, this gets written to she shortcut exactly like I want it.

Does anyone have an idea how to get this done for the target-field?

[AdmiralAlkex]

Hi and Welcome to the forums!

I can't reproduce it, if I run this:

FileCreateShortcut("%SystemRoot%\notepad.exe", @DesktopDir & "\notepad.exe - Shortcut")

Then the "target" field says:

%SystemRoot%\notepad.exe

What we need from you to give any help is a reproducer (short working/runnable) script, just like the one above. But one that fails.

[Ascend4nt]

Might want to check that the 'ExpandEnvStrings' option is set to 0. From Help:

Opt("ExpandEnvStrings", 0)  ;0=don't expand, 1=do expand

[woffi]

Hi and Welcome to the forums!

I can't reproduce it, if I run this:

FileCreateShortcut("%SystemRoot%\notepad.exe", @DesktopDir & "\notepad.exe - Shortcut")

Ok, this works here to. But when I run this:

FileCreateShortcut("%LogonServer%\notepad.exe", @DesktopDir & "\notepad.exe - Shortcut")

... %logonserver% gets substituted by the contents of the environment variable. Apparently the OS handles this variable special. Strange: even if I do a "set logon=%logonserver%" and then use the new variabls %logon% in my script, it get's substituted. I have no idea what's going on there.

Oh, BTW: this is under Windows 7. I have yet to try if it's the same under XP.

[woffi]

Might want to check that the 'ExpandEnvStrings' option is set to 0. From Help:

Opt("ExpandEnvStrings", 0)  ;0=don't expand, 1=do expand

This changes the behavious when I use %systemroot%, but curiously %logonserver% gets expanded, no matter how the option ist set.

[woffi]

Oh, BTW: this is under Windows 7. I have yet to try if it's the same under XP.

Just checked it: with XP everything works like it should.

MAybe there's a system-setting in WIndows 7 to control this?

[AdmiralAlkex]

Ok, this works here to. But when I run this:

FileCreateShortcut("%LogonServer%\notepad.exe", @DesktopDir & "\notepad.exe - Shortcut")

... %logonserver% gets substituted by the contents of the environment variable. Apparently the OS handles this variable special. Strange: even if I do a "set logon=%logonserver%" and then use the new variabls %logon% in my script, it get's substituted. I have no idea what's going on there.

Oh, BTW: this is under Windows 7. I have yet to try if it's the same under XP.

I'm sorry I missed that I had that variable. When I run the code above it points to my local pc (I'm not on a domain):

\\ADMIRAL-PC\notepad.exe

Annoying, perhaps, but what is the point of this thread? According to what I can find %LOGONSERVER% is for login scripts, so if you use it that way the shortcut will always point to the right place anyway.

Perhaps someone can offer you another solution if you tell us what you are actually doing, and why a "absolute" path is bad.

Edited July 8, 2010 by AdmiralAlkex

[woffi]

Annoying, perhaps, but what is the point of this thread? According to what I can find %LOGONSERVER% is for login scripts, so if you use it that way the shortcut will always point to the right place anyway.

No - it will point to the place that was right when the shortcut was created, which is noct necessarily the same when the shortcut is executed.

Perhaps someone can offer you another solution if you tell us what you are actually doing, and why a "absolute" path is bad.

Well, there's a reason this environment variable exists, much like there's a reason for %systemroot% etc.

We have some applications that are available on every domain-controller. The idea behind this is, that every user starts the application from the server that is closest (= fastest) and also currently available, so we copy links with "%logonserver%..." to the users desktop (actually it's more complex, but you get the idea).

So if someone in California creates a link like this, the link should not point statically to the server in California if the user in New York tries to start the application.

See the point? Many other practical scenarios exist.

[Ascend4nt]

What about wrapping it like this?:

ChrW(0x25)&"logonserver"&ChrW(0x25)

(That's the equivalent of "%logonserver%"). If that too gets expanded - I'd take a guess that the O/S is 'intervening' somehow.