I suggest whoever told you to do that takes a "Windows XP for dummies" course. Neither you or anyone else except the developer have any control over what icons appear there, unless the software has an option to not display its icon.

Is there some reason why you have posed your question in a 'Reply' thread rather than starting a new topic?

Hi
Can I have packaging standards supposed to be followed for system tray ikons. As we are supposed todelete the system tray ikons if we have a shortcut under start menu programs. Please provide a detailed or short description regarding the process need to be followed when we have any system tray ikons in the application. Fast responce will ve very much helpful for application release.

Thanks and Regards
MV

Hi Michael,
we forgot something vital: We need to tell the MSI, that its source is compressed again.
Load  ACCESSRT.MSI into ORCA, go to View - Summary Information... and set
  the flag on "Compressed by default" and remove the flag from "Administrative Image".
This should do the trick
Regards, Nick

Hi Nick,

thanks for your detailed and professional support and hint; IT WORKS [:)], besides the penny issue of needed  directory (see the error message im eventlog) despite of making a cab. But no problem; copy the whole Directoy were the msi and cab is - and it works.

I guess, something goes wrong while building the cab (the GDIPLUS.DLL is missing)
-----------------
"Produkt: Microsoft Office Access 2003 Runtime -- Fehler 1309. Fehler beim Lesen von Datei: C:\Dokumente und Einstellungen\Administrator\Desktop\Access Runtime 2003 SP2\FILES\Programme\Microsoft Office\OFFICE11\GDIPLUS.DLL.  Systemfehler 3. Überprüfen Sie, ob die Datei existiert und ob Sie darauf zugreifen können."
-----------------

Sorry; for German Windows XP. Analogously in English:

"Error 1309. Error reading from file......GDIPLUS.DLL" Error 3.Verify that the file exists and that you can access it."

Regards, Michael

Hi Michael,
apparently we both could write in german, but lets try it in english to make it world readable...

We got several problems here:
1. ACCESSRT.MSI lacks the 'AdminExecuteSequence' table. Because of this, a admin install isn't possible out of the box.
2. mainsp2ff.msp would be to big to deploy with this package, it makes it inefficient.
3. Maybe a setup.exe wrapper would make things easier here?

To deploy Access RT with SP2 (or SP3) injected, we have to do the following steps:
1. We need to append the 'AdminExecuteSequence' table to ACCESSRT.MSI.
If you have access to the Installer SDK, search for 'Sequence.msi' and open it in ORCA.
export the 'AdminExecuteSequence' table to your work directory.
Now open 'ACCESSRT.MSI' in ORCA and import the 'AdminExecuteSequence.idt' file from your work directory.
Save it and exit.
in C:\workdir\ type:
msiexec /a ACCESSRT.MSI TARGETDIR=C:\workdir\admin
This write an admin installation point.
now cd to C:\workdir\admin and type:
msiexec /a ACCESSRT.MSI /p ..\MAINSP2ff.msp TARGETDIR=C:\workdir\admin
This applies the SP2 to the install point.
Now we have to generate the new CAB-file for the SP2-version. You need WiMakCab.vbs from the SDK to do this.
Make sure it lies in the path or copy it to C:\workdir\admin.
cd to C:\workdir\admin and type:
cscript WiMakCab.vbs ACCESSRT.MSI ACCESSRT /L /C
After this you have the SP2-version of ACCESSRT.MSI and ACCESSRT.CAB in your C:\workdir\admin.

And finally load  ACCESSRT.MSI into ORCA, go to View - Summary Information... and set
the flag on "Compressed by default" and remove the flag from "Administrative Image".

Now, you could add your SP2-version of the runtime to your distribution.

Regards, Nick

Hi Nick,

an exe type CA !? You mean msiexec.exe...or what!? I try also this CA with exe (instead of msi)

msiexec /i .... ACCESSRT.msi  /PATCH=.... mainsp2ff.msp -qn

no luck, too....

Grützi, Michael

Hi Mike,
you can't use an nested CA for this purpose.
Use an exe type CA and sequence it after InstallFinalize.
Regards, Nick

[font="microsoft sans serif"]Access Runtime couldn't updated with this method!! I try it first as other office slipstreaming methods known.
[font="microsoft sans serif"]
[font="microsoft sans serif"]All other Office 2003 Pro. files were updating except the Runtime [:(] see here:
[font="microsoft sans serif"]
[font="microsoft sans serif"]http://www.cetix.de/OfficeNews/Thread142604-Access_Runtime_2003_when_slipstreaming_SP2.aspx
[font="microsoft sans serif"]
[font="microsoft sans serif"]Access Runtime 2003 slipstreaming SP2 won't work!!
[font="microsoft sans serif"]
[font="microsoft sans serif"]So, I try to make an nested msi with the msp (custom action); any -other- clues!?
[font="microsoft sans serif"]
[font="microsoft sans serif"]Mike
[font="microsoft sans serif"]
[font="microsoft sans serif"]

mikle_1,

Maybe I'm missing something here, but can't you create an admin install point of the Access Runtime and then patch the install point up to SP2

msiexec /a "access runtime 2003.msi"

msiexec /p "mainsp2ff.msp" /a <path to admin install point>

When an installation is performed from the patched admin installation point SP2 of Access Runtime will be installed.

Hope this helps,

Dunnpy