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
- :
- InstallShield 2008 rips out Directory table records during compile
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
‎Mar 24, 2008
06:44 PM
InstallShield 2008 rips out Directory table records during compile
Annoying InstallShield 2008 directory table compile behavior
I need to have a NETWORKPATH Directory table variable for when users are connecting to an instance of our program on a network.
In the Properties, I define it as an indirect, for the browse dialog
_NetworkClientBrowse NETWORKPATH
In the Directory table I define its default as the INSTALLDIR
NETWORKPATH INSTALLDIR .
INSTALLDIR itself is defined with a default value equal to the default installation value of the installer. I understand that directories need defaults. So why is InstallShield ripping out NETWORKPATH when it should recognize that it resolves to the normal installation default?
When the installer compiles, it RIPS OUT the NETWORKPATH record from the Directory table.
This is annoying because the installer works fine if I go back into the table and HAND EDIT the NETWORKPATH directory back in.
It seems that InstallShield has been programmed to DUMP any directory variable that is not DIRECTLY being used as the default of a component or a feature.
EVEN WHEN THE VARIABLE HAS BEEN PUT THERE ON PURPOSE.
This did not happen in IS 9.0. The NETWORKPATH record stayed put in the Directory table when compiled.
Anyone have any suggestions for ways around this. Define all such variables in the Properties table?
I need to have a NETWORKPATH Directory table variable for when users are connecting to an instance of our program on a network.
In the Properties, I define it as an indirect, for the browse dialog
_NetworkClientBrowse NETWORKPATH
In the Directory table I define its default as the INSTALLDIR
NETWORKPATH INSTALLDIR .
INSTALLDIR itself is defined with a default value equal to the default installation value of the installer. I understand that directories need defaults. So why is InstallShield ripping out NETWORKPATH when it should recognize that it resolves to the normal installation default?
When the installer compiles, it RIPS OUT the NETWORKPATH record from the Directory table.
This is annoying because the installer works fine if I go back into the table and HAND EDIT the NETWORKPATH directory back in.
It seems that InstallShield has been programmed to DUMP any directory variable that is not DIRECTLY being used as the default of a component or a feature.
EVEN WHEN THE VARIABLE HAS BEEN PUT THERE ON PURPOSE.
This did not happen in IS 9.0. The NETWORKPATH record stayed put in the Directory table when compiled.
Anyone have any suggestions for ways around this. Define all such variables in the Properties table?
(2) Replies
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 25, 2008
05:39 AM
Directory tables that are left unused in the project are assumed to be unnecessary and are dropped during the build. This is documented in the InstallShield 2008 Release Notes.
If you don't want this behavior to occur, you can disable it by going to the Releases view and changing the "Keep Unused Directories" from "No" to "Yes".
If you don't want this behavior to occur, you can disable it by going to the Releases view and changing the "Keep Unused Directories" from "No" to "Yes".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 26, 2008
04:39 PM
Thank you. I hadn't noticed that new setting -- "Keep Unused Directories".
That makes the whole issue very easy to resolve.
Thank you much for pointing it out.
Not all of us have eagle eyes for everything.
That makes the whole issue very easy to resolve.
Thank you much for pointing it out.
Not all of us have eagle eyes for everything.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)