Error 1420 : while creating a shortcut

[smarr]

I,

Having an issue creating a shortcut in one of my apps. I just took the example from the documentation, including a verification in order to be sure that the target exe realy exists and I am still getting the same error.

I run Windows 8.1 with admin privileges, UAC disabled. Manually I can create it, but by program it always fails :

************************************************************

*** Lancement du débogage ***

==============================
Dim 10/05/2015 16:11:34
WinBatch 32 2014B
WIL DLL 6.14bnb
D:\Winbatch\wbt\DiversSrc\test4.wbt
Windows platform: NT, version: 5.1, build: 2600 (Service Pack 3)
ErrorMode: @CANCEL
Valid Code Signature: Yes
UAC Manifest Settings: level="asInvoker" uiAccess="false"
UAC Elevation Level: Unsupported Platform
==============================

startdir=ShortCutDir( "Desktop", 0, 0 )
(46) VALUE=> STRING => "C:\Users\raphael\Desktop"

DirChange( startdir )
(46) VALUE=> INT => 1

dest = StrCat( DirWindows(0), "notepad.exe" )
(46) VALUE=> UNICODE => C:\WINDOWS\notepad.exe

size = filesize(dest)
(46) VALUE=> INT => 221184

ShortCutMake( "mynotepad.lnk", dest, "", "", @NORMAL, 0 )
(3046) VALUE=> INT => 0

TERMINAL WIL ERROR=>1420 (Fonctions Shortcut : Erreur lors de l'enregistrement chargement du fichier Shortcut)

;;;END OF JOB;;;

[td]

You state, 'I run Windows 8.1' but your debug trace file shows Windows XP service pack 3.  If you are attempting to run WinBatch on Windows 8.1 in XP compatibility mode, stop doing it!  Running WinBatch in compatibility mode is not supported.   

[smarr]

The original machine was this one : (the other one is only my dev environment)

************************************************************

*** Debug Initialized ***

==============================
Mon 11/05/2015 01:39:29
WinBatch 32 2014B
WIL DLL 6.14bnb
C:\Temp\TEST4.exe
Windows platform: NT, version: 6.3, build: 9600
ErrorMode: @CANCEL
Valid Code Signature: No
UAC Manifest Settings: level="requireAdministrator" uiAccess="false"
UAC Elevation Level: Standard User or Disabled
==============================

startdir=ShortCutDir( "Desktop", 0, 0 )
(0) VALUE STRING => "C:\Users\Administrateur\Desktop"

DirChange( startdir )
(0) VALUE INT => 1

dest = StrCat( DirWindows(0), "notepad.exe" )
(0) VALUE UNICODE => C:\WINDOWS\notepad.exe

size = filesize(dest)
(0) VALUE INT => 0

ShortCutMake( "mynotepad.lnk", dest, "", "", @NORMAL, 0 )
(5328) VALUE INT => 0

TERMINAL WIL ERROR=>1420 (Shortcut functions: Error saving shortcut file)

;;;END OF JOB;;;

[td]

The original machine was this one : (the other one is only my dev environment)

The path "c:\documetns and settings\<user>\desktop" is the usual path for desktop links on XP.  The path "c:\users\<users>\desktop" is used on Vista and newer.  So again, if you set compatibility mode for WinBatch on your development machine or any other, you would do well to stop.

The error produced by ShortCutMake is the result of an undocumented  change Microsoft made to a Windows shell interface. You need to specify the full path to the link file in the functions first parameter.  So your function call would look something like the following:

Code (winbatch) Select Expand

ShortCutMake( startdir:"\mynotepad.lnk", dest, "", "", @NORMAL, 0 )

[smarr]

Thanks, works better as sugested

[DAG_P6]

The error produced by ShortCutMake is the result of an undocumented  change Microsoft made to a Windows shell interface. You need to specify the full path to the link file in the functions first parameter.  So your function call would look something like the following:

I wasn't aware that a relative path was ever valid in a shortcut, since the shell makes any path you input into the Target text box fully qualified.

[td]

As anyone with Windows software development experience will tell you, it has always been the case in Windows that the Windows UI does not necessarily fully mirror the behavior of the underlying API.  Up to and including Windows 7 the underlying shell API interface would use the current directory when a full path was not provided alone with the link's file name and extension.  This behavior didn't change until Windows 8.whatever when the shell COM based API interface save method began requiring a full path.

The new behavior holds true for Windows 10, as well.

[DAG_P6]

As anyone with Windows software development experience will tell you, it has always been the case in Windows that the Windows UI does not necessarily fully mirror the behavior of the underlying API.

Of that I am well aware; the user interface tries to be "user friendly," whatever that is, while the underlying API lets programmers have full rein to get things done. I simply haven't had a need to try to use ShortcutMake or the underlying API to create a shortcut with a relative path.

OTOH, I have used environment variables with the user interface and with ShortcutMake  to create more portable shortcuts. For example, I wrote a utility that scans a collection of shortcuts, replacing all ocurrances of the directories named in a list of environment strings with the environment string. It reads both lists from a specified INI file.

[td]

I have very little personal interest in shortcuts with or without fully qualified paths. Simply don't have much use for them.  However, I do have a professional interest in them because our users are interested in them.  And because of an unfortunate example in the Consolidated WIL Help file, they have run afoul of MSFT's change to the shell's shortcut API on a couple of occasions. 

Hopefully, the help example will be changed for the next release.