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: Is there an environment variable or debug indicator?
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
‎Jan 11, 2010
05:20 PM
Is there an environment variable or debug indicator?
I am trying to get my logic going without having to call the copy and special registration services of my component. This both takes a long time and can mess up my development machine. I need a way to embed a
If (!DEBUGGING) then
// DO this stuff only on non-debugging "normal" installations
endif;
Is there something like this in IS 10?
If (!DEBUGGING) then
// DO this stuff only on non-debugging "normal" installations
endif;
Is there something like this in IS 10?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 11, 2010
05:51 PM
Perhaps see the help topic "Using Preprocessor Statements to Debug the Script".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 12, 2010
09:02 AM
This is not a good solution. This I could do by simply hardcoding a g_bDebug variable setting it = TRUE or = FALSE which is much much easier than embedding a flag in the buried IS compiler settings (which took me about 5 minutes to even find) were it is even easier to forget.
This should be inherent like it is in every compiler. I should know if I am running in the debug environment or deployment environment without having to generate a bunch of code to complicate this. Why does IS as long as it has been out, not have a primitive feature like IS_DEBUGGING_ENV?
#if DEBUG should be an IS primitive. Install shield should always provide the operation mode of the code being in debug or not.
If you try to get me to do something so clunky, then I have a bug waiting to happen in that I have to remember when I turned on debug and when I didn't so I don't build a gelded install.
Why would I want to hide in the complexity of the IS settings the fact that I have bound my app to being debug no matter what environment I have including deployment? In short, I wouldn't.
Things like this are extremely easy to implement if you are the person developing the compiler.
This should be inherent like it is in every compiler. I should know if I am running in the debug environment or deployment environment without having to generate a bunch of code to complicate this. Why does IS as long as it has been out, not have a primitive feature like IS_DEBUGGING_ENV?
#if DEBUG should be an IS primitive. Install shield should always provide the operation mode of the code being in debug or not.
If you try to get me to do something so clunky, then I have a bug waiting to happen in that I have to remember when I turned on debug and when I didn't so I don't build a gelded install.
Why would I want to hide in the complexity of the IS settings the fact that I have bound my app to being debug no matter what environment I have including deployment? In short, I wouldn't.
Things like this are extremely easy to implement if you are the person developing the compiler.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 12, 2010
10:39 AM
You don't have to specify preprocessor defines on the Build > Settings dialog. I agree that having to set and unset this definition there would be awful. Instead you can specify additional preprocessor defines on your Release's Build tab, in the option "Compiler Preprocessor Defines". This way you can create two or more nearly identical release configurations and choose whether to provide the DEBUG definition on each.
This is equivalent to how Visual Studio does things for C++, except that it isn't automatically set up for you. In our experience, very few people want to have such differences in their InstallScript code, so we've avoided confusing people unfamiliar with such a Debug/Release convention.
This is equivalent to how Visual Studio does things for C++, except that it isn't automatically set up for you. In our experience, very few people want to have such differences in their InstallScript code, so we've avoided confusing people unfamiliar with such a Debug/Release convention.