Done SHORTCUT suggestions

[Charles Dye]

1. If the target command does not contain any of : / \ or %, and does not exist in the current directory, do a %path% search for it. For example:

shortcut notepad.exe "" "" "" "%@shfolder[16]\test1.lnk" 1

If there is not a notepad.exe in the current directory, search the path for it.


2. Add a fourth optional parameter uac. If uac begins with E, run the command elevated. If it begins with N, run the command unelevated. If uac is not present, do not set the shortcut's elevation level.

 

[djspits]

The suggestion above pertains to Creation Mode.

In Display Mode, don't fail on an empty Command field.

If the target is no longer accessible Windows returns a modified data-set with an empty Command field. However, other fields can still be examined (using the Explorer) and show all info present except the command field which is empty. In fact, if e.g. a missing device is reconnected, the link becomes valid again.

I would suggest that it is unnecessary for SHORTCUT to generate an error if the target has become invalid. The user could still reuse the rest of available info to decide how to respond. Search for and modify to a different location, ask user to reconnect a certain device?

@Charles Dye I suspect that currently TC only helps with assembling the .lnk file and that the OS "executes" them. If I'm wrong, and TC does some preprocessing before passing the link to the winapi, then Command, Args and Directory could be any valid TC expression. That would make for much smarter links.

 

[Charles Dye]

@Charles Dye I suspect that currently TC only helps with assembling the .lnk file and that the OS "executes" them. If I'm wrong, and TC does some preprocessing before passing the link to the winapi, then Command, Args and Directory could be any valid TC expression. That would make for much smarter links.

Yes, of course. You can use .LNK files on Windows when Take Command isn't installed, yeah?

 

[djspits]

Agreed, Charles. A "shortcut on TC steroids" would need its own extension, obviously. It would be a better alternative rather than a improved version.

Personally, I would be much relieved if something was done about having to deal with *nine* arguments, even if you're modifying only one.

At the command-line:

C:\ > SHORTCUT MyLink.lnk /=

could display the usual dialog but (!) also properly initialize it with the values already in the existing hyperlink. That alone would be a great time saver! Actually, I rather suspect that the current state of affairs is actually ... a ... bug?


In a script:

Something that would prevent the hassle of having to @execarray the shortcut, modify one cell and recreate it. (Yes, I have a subroutine for that) It seems that a little creative use of command-line switches could prevent all that. /1, /2, etc could all correspond with the arguments in standard order.

 

[Charles Dye]

Personally, I would be much relieved if something was done about having to deal with *nine* arguments, even if you're modifying only one.

Oh yeah. When I wrote MKSC, I started with a list of things I wanted to be different from SHORTCUT. #2 on the list was "Optional arguments are optional, and may be entered in any order."

 

[w_krieger]

Is it possible to read the shortcut before modifying it?

 

[Charles Dye]

Is it possible to read the shortcut before modifying it?

Certainly.

 

[Charles G]

Is it possible to read the shortcut before modifying it?

shortcut sample.lnk

See the output from this command - assuming sample.lnk is in the CWD

 

[rconn]

The suggestion above pertains to Creation Mode.

In Display Mode, don't fail on an empty Command field.

If the target is no longer accessible Windows returns a modified data-set with an empty Command field. However, other fields can still be examined (using the Explorer) and show all info present except the command field which is empty. In fact, if e.g. a missing device is reconnected, the link becomes valid again.

I would suggest that it is unnecessary for SHORTCUT to generate an error if the target has become invalid. The user could still reuse the rest of available info to decide how to respond. Search for and modify to a different location, ask user to reconnect a certain device?

It's not TCC that's returning the error; it's Windows. TCC calls the Windows API ResolveLink to retrieve that information. If the target is no longer accessible, ResolveLink returns an error (and doesn't populate the other fields).