12 replies to this topic

[Superfreak3]

I've had this issue in the past, but I'll post the question again:

I have some shortcuts that I would like to tie to executable components.  However, these shortcuts will contain user specific server names.  We are not prompting the user for the server name as per the user's request.  They would like to edit the command line of the shortcut after it is placed during our install.  

Here is where the problem comes in.  If the shortcut points to a component that will be/is replaced with a higher versioned file, the shortcut will be overwritten/recreated and the user specific server name is gone.  The end user would have to repeatedly modify the shortcut after subsequent releases.

Initially we had tied most shortcuts which required user modification to Never Overwrite components.  The limitation to this is that new shortcuts cannot be tied to the same component because the shortcut will not be built (the Never Overwrite component is not replaced during the upgrade).

With that said, and I hope you know what I'm shooting for here, is there any backdoor way to preserve shortcuts (end user entered modifications) who's target file (component) may be replaced in future upgrades with higher versioned files?

If you need more information, please let me know!

THANKS!

[Superfreak3]

I've even tried shortcuts not tied to a component (component field left blank) as a test with the s flag removed from the ReinstallMode property.  I edited the command line of the shortcut following the initial install.  The upgrade overwrote my changes.

This didn't work either.

[Ian Blake]

Might I suggest ypu stop trying to preserve them.  Try to recreate identical shortcuts.

Add a custom action just after AppSearch in the execute sequence to extract the command line from the shortcut if it is present.  Stuff this into a property that you can use in the argument of the shortcut table.

hope this helps

[Superfreak3]

That works for me, Ian.  Would a VBScript CA handle the job or would InstallScript be better?

That being asked, what would the command lines/arguements attribute be called?  In other words, what exactly am I grabbing in my script to equate to a Property.  What tag does the 'Arguements' have on the shortcut?

I hope you understand what I'm asking!  I'm eager to see this work.

Thanks again, Ian!!!!!

[dbareis]

Quote (Superfreak3 @ July 23 2002,04:57)

I have some shortcuts that I would like to tie to executable components.  However, these shortcuts will contain user specific server names.  We are not prompting the user for the server name as per the user's request.  They would like to edit the command line of the shortcut after it is placed during our install.

Wouldn't it be a lot easier and cleaner to use a system environment variable to hold the server name you wish in the shortcuts and create the shortcuts (to your possibly new requirements) every time.  If the server name is wrong a simple endit uninstall/reinstall will fix. No magic, restrictions or editing of shortcuts required...

Bye
Dennis

[luke_s]

Couldnt you add another component that had the shortcut in, and another one with the executable. This way the executable would be upgraded and the shortcut would stay the same becuase it would not be linked to the executable component?

[Ian Blake]

Superfreak - You could use C, VB or InstallScript. to get the information.  However it can be difficult to to read the argument from a shortcut.  Darwin shortcuts are particulaly tricky to manipulate. Dennis' suggestion that you store a copy of the argument external to the shortcut is a good one.  It would be better to use a registry key rather than an environment variable.  Users should not be editing shortcuts directly so your configuartion utility could keep the registry key uptodate.  The installer is quite good at reading registry keys.  

As for the argument in the shorcut table. This is type formatted so if you fill it in as [MYPROPERTY] then the contents of MYPROPERTY will be the argument of the resultant shortcut.

Dennis - I think a registry key would be a much better solution than an an Environment variable.  Environment variables are essentially for legacy command line utilities.  I think your general point is good.

Luke - No,  this is not desirable.  You want to keep your shortcuts tightly bound with the associated program.  If only to avoid ICE warnings.

[Superfreak3]

Thanks for all the suggestions/information folks.  I'll digest it all and see what I can do.

Thanks Again!!!!

[Superfreak3]

The way it sounds, the arguement of the shortcut could be stored for future reference.  The only problem is that we don't know the end user's servername/IP address beforehand as they are editing this portion of the arguement after the installation/upgrade completes (I know this is bad but it's just our current state of affairs).  So, if I'm understanding this correctly, what we store (registry key) will not be the 'correct'/end-user-edited arguement but that which is placed during the install/upgrade (which, again, does not include the end users required parameters).  It still seems to me that I would have to somehow grab the arguement that is currently on the target system (if this is an upgrade), and I guess this is tricky.

I guess the best solution to my problem (maybe not the best, but what my level of expertise provides me) is to maybe present a servername dialog into which the end user would enter the name or address.  I could then plug this property into the arguement for shortcut build/rebuild.

It sounds to me like preserving the arguement is a bit tricky and won't apply to my problem.  Am I safe in assuming this based on the information I've provided or have I just muddied the waters?

Thanks again!!!

[Ian Blake]

I am not very knowledgeable about the shell but I think you need code something like this C code. I have not tried this. I think the VB equivalent may be a little easier.  I am sure someone who has used the shell more recently than me can point out many problems with this offering.

IShellLink *pShellLink = NULL;
IPersistFile *pPersistFile = NULL;
HRESULT hResult;
char args[INFOTIPSIZE];

CoInitialize(NULL);

CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, &pShellLink);

if (SUCCEEDED(hResult))
{
  hResult = pShellLink->QueryInterface(IID_PersistFile, &pPersistFile);
  if (SUCCEEDED(hResult))
  {
     hResult = pPersistFile->Load(L"\\Document & Settings\\ etc etc....");
     if (SUCCEEDED(hResult))
     {
        hResult = pShellLink->GetArguments(Args, INFOTIPSIZE);
     }
  }

}

if (pPersistFile) pPersistFile->Release();
if (pShellLink) pPersisFile->Release();

CoUninitialize();

if (SUCCEEDED(hResult))
{
  MsiSetProperty(hInstaller, "LASTARGS", args);
}
else
{
  MsiSetProperry(hInstaller, "LASTARGS", "*Invalid*");
}

return INSTALL_SUCCESS;

[dbareis]

Quote (Ian Blake @ Aug. 05 2002,18<!--emo&)

Dennis - I think a registry key would be a much better solution than an an Environment variable.  Environment variables are essentially for legacy command line utilities.  I think your general point is good.

The reason I said environment is that info is readily accessible to the MSI (use "[%ENVVAR%]" in shortcut etc) and that the user can easily change it without needing a separate application or regedit (this also makes it safer).
Note that environment variables are coming out of the woodwork, I don't know about XP but my Win2000 box has more than you can shake a stick at...

To preserve value, if you don't like the env-var approach: Havene't tried but setting a property to "invalid" and then attempting to read a registry value or INI file via appsearch table might work without requiring CA code (not sure what happens if search fails). Of course you write the value out later.

[Superfreak3]As for users not typing config correctly up front, an uninstall/reinstall or probably repair would fix this...

Of course the other main approach would be for the shortcut to kick off a VBS which obtains the correct value from somewhere and starts the app.

Bye,
Dennis

[Superfreak3]

With all this information, I was hoping I could present this a different way and maybe get some pointers based on my example.  

We are placing a component, let's say, Test.exe which has a shortcut associated with it.  After the installation/upgrade, the shortcut resides on the desktop with the following attributes:

Arguement:  ServerName=<ServerName>;dbname=Office;Runin=C:\DBDIR
Target:  C:\Junk\Test.exe.

(<ServerName> is the initial value of the property SERVERNAME as assigned in the property table.  This was set up this way incase we institute a dialog to capture this information.)

Following the installation/update, the end user may edit the arguement portion of the short cut as one of the following:

ServerName=MYSERVERNAME;dbname=Office;Runin=C:\DBDIR or ServerName=180.1.1.2;dbname=Office;Runin=C:\DBDIR .

If Test.exe's version is bumped, it will be installed with a subsequent upgrade and the arguement of the shortcut will return to:

ServerName=<ServerName>;dbname=Office;Runin=C:\DBDIR.

How can I preserve this:  ServerName=MYSERVERNAME;dbname=Office;Runin=C:\DBDIR so that it will not be overwritten?  How can I save it somewhere and overwrite the original arguement after an upgrade?

I'm trying to develop some type of work around and my head is starting to spin.  I was just hoping that presenting it this way might make what I want to do clearer.

Thanks for all the help!!!!

[Superfreak3]

Here's what I did to solve my problem:

I wrote VBScript code to copy any desktop shortcuts (whose user edited arguements would be overwritten otherwise) to a 'save' file (.lnk file to .sav).

Later in the install, this 'save'd desktop shortcut replaces that which was placed with the upgraded component (shortcut contains generic arguements) via VBSCript also.

It's weak, but hey, it works!  I'll also have to add any future effected shortcuts to the script, but I'll live with that.

Thanks all for any pointers!!