This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: duplicate desktop icons when logging on as new user
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 28, 2007
03:52 AM
duplicate desktop icons when logging on as new user
When I install our app a single desktop icon appears as expected. Icons also appear under the Start menu.
When I log off the administrative account and log back in as a standard user account the single desktop icon appears. When I click on the desktop icon to run the app the MSI engine starts, prompts for the media, and then creates a duplicate icon ... this time under the User's Desktop folder. The original icon was placed under the All Users' Desktop folder.
How can I prevent the icon from being installed to the User's Desktop folder.
I have a single Desktop Shortcut object in my setup.
It is associated with a single component which also includes the Start menu icons.
The start menu icons do not have this problem, just the desktop.
Below is the single row from the Shortcut table that describes this object.
AppDesktop, DesktopFolder, XMAPED5|DeLorme XMap Edit 5, ApplicationShortcuts, [INSTALLDIR]XMapEdit5.exe, NULL, "Description", NULL HOTKEY, NULL ICON, NULL ICON INDEX, 1, NULL WkDir, NULL DisplayResourceDll,
This is not an advertised shortcut. I had previously tried to associate an advertised shortcut with a DIM file but InstallShield sets a file as the keyfile when processing DIMs and that causes ICE43 errors.
When I log off the administrative account and log back in as a standard user account the single desktop icon appears. When I click on the desktop icon to run the app the MSI engine starts, prompts for the media, and then creates a duplicate icon ... this time under the User's Desktop folder. The original icon was placed under the All Users' Desktop folder.
How can I prevent the icon from being installed to the User's Desktop folder.
I have a single Desktop Shortcut object in my setup.
It is associated with a single component which also includes the Start menu icons.
The start menu icons do not have this problem, just the desktop.
Below is the single row from the Shortcut table that describes this object.
AppDesktop, DesktopFolder, XMAPED5|DeLorme XMap Edit 5, ApplicationShortcuts, [INSTALLDIR]XMapEdit5.exe, NULL, "Description", NULL HOTKEY, NULL ICON, NULL ICON INDEX, 1, NULL WkDir, NULL DisplayResourceDll,
This is not an advertised shortcut. I had previously tried to associate an advertised shortcut with a DIM file but InstallShield sets a file as the keyfile when processing DIMs and that causes ICE43 errors.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 28, 2007
09:22 AM
Has anyone else ever seen behavior like this? It seems to happen for anyone who is not the person who installed the app.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 28, 2007
09:53 AM
Is this installation being performed with ALLUSERS equal to 1?
If not, I believe that would explain this behavior.
If not, I believe that would explain this behavior.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 28, 2007
10:33 AM
The log file reports ALLUSERS = 1.
I am trying a different approach. I bet when I log under a different user that the value of DesktopFolder is being redefined even though ALLUSERS = 1. Therefore it does not think this part of the component is installed.
So, I am using SHGetFolderPath to get the value of:
#define CSIDL_COMMON_DESKTOPDIRECTORY 0x0019 // All Users\Desktop
as is defined in ShlObj.h. I believe that DesktopFolder is being defined as CSIDL_DESKTOP 0x0000 which is not the AllUsers desktop folder. My approach that I am testing right now is to create a custom directory called COMMONDESKTOP | TARGETDIR | . in the directory table. I then assign this as the _Directory foreign key in the Shortcut table. When my custom action runs and I find the value I then update the COMMONDESKTOP using MsiSetProperty.
I am trying a different approach. I bet when I log under a different user that the value of DesktopFolder is being redefined even though ALLUSERS = 1. Therefore it does not think this part of the component is installed.
So, I am using SHGetFolderPath to get the value of:
#define CSIDL_COMMON_DESKTOPDIRECTORY 0x0019 // All Users\Desktop
as is defined in ShlObj.h. I believe that DesktopFolder is being defined as CSIDL_DESKTOP 0x0000 which is not the AllUsers desktop folder. My approach that I am testing right now is to create a custom directory called COMMONDESKTOP | TARGETDIR | . in the directory table. I then assign this as the _Directory foreign key in the Shortcut table. When my custom action runs and I find the value I then update the COMMONDESKTOP using MsiSetProperty.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 28, 2007
11:59 AM
Well, there is still a problem and I am not certain what to do about the problem.
1. SHGetFolder - when I call the function it returns the correct value.
2. I noticed that just before the function is called that I get the following msg:
[CODE]InstallShield 12:29:23: ProductCode is {55BC9FA0-591C-4B0A-A744-B75F204FA6CB}
MSI (s) (54!30) [12:29:23:171]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.[/CODE]
3. I am not certain why ALLUSERS is being deleted. Is this something that happens when running as a standard user?
4. Later in the script, when the shortcut is written the following lines appear.
[CODE]MSI (s) (54:B0) [12:31:48:703]: Executing op: SetTargetFolder(Folder=16)
MSI (s) (54:B0) [12:31:48:703]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\winxpuser\Desktop
MSI (s) (54:B0) [12:31:48:703]: Executing op: ShortcutCreate(Name=XMAPED5|DeLorme XMap Edit 5,,,FileName=C:\Program Files\DeLorme\XMapEdit Internal\XMapEdit5.exe,,,,,,ShowCmd=1,)
MSI (s) (54:B0) [12:31:48:718]: Executing op: SetTargetFolder(Folder=2\DeLorme\XMap Edit 5\)[/CODE]
Based on the above lines I can make the following assumptions:
Folder=16 SHOULD be the common desktop folder per ShlObj.h define.
The value returned though is the %USERPROFILE% value from HKCU instead of HKLM.
The value I set in my custom action seems to be ignored completely when the shortcut is created!
Sometimes Windows just gives me fits *twitches uncontrollably*
1. SHGetFolder - when I call the function it returns the correct value.
2. I noticed that just before the function is called that I get the following msg:
[CODE]InstallShield 12:29:23: ProductCode is {55BC9FA0-591C-4B0A-A744-B75F204FA6CB}
MSI (s) (54!30) [12:29:23:171]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.[/CODE]
3. I am not certain why ALLUSERS is being deleted. Is this something that happens when running as a standard user?
4. Later in the script, when the shortcut is written the following lines appear.
[CODE]MSI (s) (54:B0) [12:31:48:703]: Executing op: SetTargetFolder(Folder=16)
MSI (s) (54:B0) [12:31:48:703]: SHELL32::SHGetFolderPath returned: C:\Documents and Settings\winxpuser\Desktop
MSI (s) (54:B0) [12:31:48:703]: Executing op: ShortcutCreate(Name=XMAPED5|DeLorme XMap Edit 5,,,FileName=C:\Program Files\DeLorme\XMapEdit Internal\XMapEdit5.exe,,,,,,ShowCmd=1,)
MSI (s) (54:B0) [12:31:48:718]: Executing op: SetTargetFolder(Folder=2\DeLorme\XMap Edit 5\)[/CODE]
Based on the above lines I can make the following assumptions:
Folder=16 SHOULD be the common desktop folder per ShlObj.h define.
The value returned though is the %USERPROFILE% value from HKCU instead of HKLM.
The value I set in my custom action seems to be ignored completely when the shortcut is created!
Sometimes Windows just gives me fits *twitches uncontrollably*
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 02, 2007
11:28 AM
What was the action that was running when the ALLUSERS property gets deleted (look for an "Action Start" message)? This could help in isolating where/why the property is being deleted.
Since the ALLUSERS property is undefined at the time the shortcut gets created, the behavior seen with the SHGetFolderPath resolution of DesktopFolder would be expected. I'm not sure why it's not installing to the path set by your custom action. If your custom action is sequenced after CostFinalize, you should use the MsiSetTargetPath API instead of MsiSetProperty. If it is sequenced before CostFinalize the action should work with MsiSetProperty.
Since the ALLUSERS property is undefined at the time the shortcut gets created, the behavior seen with the SHGetFolderPath resolution of DesktopFolder would be expected. I'm not sure why it's not installing to the path set by your custom action. If your custom action is sequenced after CostFinalize, you should use the MsiSetTargetPath API instead of MsiSetProperty. If it is sequenced before CostFinalize the action should work with MsiSetProperty.