In my project, I use installshield to insert an environment variable during installation.
PEAK_LIMIT = 1000
However, if I change the value to say - 1500, then during re-installation with higher versions causes the value to be reset to 1000. Is there a way to preserve the current value 1500 instead of resetting?
Thanks
It sounds like you have a hard coded value in your Environment table. Substitute it out with a property that equals that value. Then use a custom action during the install to assign the current value to the property if it has a value. This way when MSI rewrites the environment variable it'll keep the value it read.
Another approach would be to create a second environment variable (PEAK_LIMIT_OVERRIDE) that has higher priority in your application. This way the installer can set the default value to what it thinks is correct and keep that apart from user controlled data.
Related
I have a GitLab Project that belongs to a Group. I've defined a number of common variables in the group that I would like to reuse in my projects. I know these variables are inherited by the project, but I would like to be able to re-assign the target group variables from the project as needed.
Is there way to target a group variable from a project? I suspect not, because using the $VAR_NAME syntax results in a warning stating the variable cannot be masked (due to the $).
"Masking" in GitLab means that it would replace the value with asterisks. I.e. *******. Which, if it is not able to, like on your screenshot, GitLab warns about.
According to the warning the variable will get expanded if such a group level variable exists; means it would do what you expect it to. Though you need to be aware, that your variables values may be in plaintext in the job log.
How it behaves depends on how you configured the group level variable in this case:
If the group level variable is set to be masked, then it will be masked in the expanded project level variable as well.
But you can not mask the expanded variable at the project level, if you did not set the group level variable to be masked in the first place.
A way to work around this uncertainty would be, to directly use the group level variable. Though I can see that this might not always be possible depending on for example differing frameworks used in the projects of a group.
When I create a new record on the Service Request (SR) application (Maximo 7.6), I would like to set the required Reported Date (SR.REPORTDATE) field blank. Before save action, the user will input data into that field. I wonder how this could be done?
Thanks for the help.
If you look in Database Configuration to see if REPORTDATE has a Default Value, I think you'll find &SYSDATE& in there. If I'm right, then you can delete that default value, save your changes, and apply your changes. Otherwise, you'll need to do as #Dex suggested.
My mind immediately goes to an automation script. A default value control or the default value setting in Database Configuration may work too and is recommended before a script if you have the expertise to confirm or deny this theory.
As for the automation script, I think you can create one with an object launch point on SR on the "add" event. The script would simply set that field to null, which shouldn't change the "required" flag either, so the rest of your needs will still be met.
mbo.setValueNull("REPORTDATE");
I have an InstallSheild msi that creates a registry key and adds a value to it. It doesn't get removed on the uninstall, because we like that functionality of remembering the value between upgrades.
My question is how can I override that value if I run the installer via command line and pass in a new value?
Right now it does a system search to find the value and if it exist it will use that one regardless of what you pass in from the cmd line parameter. I was hoping I could add a condition in somewhere to state if its in the cmd line use that instead of the old value.
one way to do it is something like that.
make your system search place the value in a temporary value.
then make a custom action that run right after you system search, that replace your value with the temporary value, if it hasn't already been set via the cmdline.
I have created one basic MSI project in InstallShield. I want to achieve one scenario. For this I'm setting one property at the time of installation using installScript function MsiSetProperty(). But I want also read the value of same property at the time of uninstallation. I need the value of property at uninstallation, which is set at the time of installation.
So is there any way to retrieve the value of property at uninstallation, which is set at the time of installation?
Reading a property at uninstallation is the same as reading it during installation: you call MsiGetProperty(), and if it's in a deferred context you have to pass it through the CustomActionData property. Note as well that setting a property during a deferred context doesn't do much.
However what's probably tripping you up is that properties, in general, are not preserved across Windows Installer sessions. There are exceptions, such as DirProperties for installed components, that are automatically preserved. But most properties are simply forgotten when the current action ends. The typical recommendation is to follow the 'remember property pattern' which, in a nutshell, consists of saving the value of the property to a registry key, and reading it back with a system search.
I just tried a workaround for this. I'm setting registry value at the time of installation & reading that property at uninstallation and setting a value of it to property.
I have a report that I developed that utilizes render variables as described here.
My prompt page has 3 check box groups filled with variables. My first box is set to required, as it contains key information that needs to be pulled. The 2nd and 3rd have optional values. When the report runs, it requires at least one of the options in box 2 and 3 to be selected.
Any idea?
If a parameter is referenced directly in a query data item, Cognos will force it's associated prompt to be required even if you set it to 'Optional'. If this is the issue, the solution is to use a prompt macro instead of the normal ?? syntax. You set a default value to pass if the prompt isn't satisfied. This allows the prompt to act like an optional prompt.
The minimum syntax is:
#prompt('prompt_name','string','')#
The third parameter is the default value. I have just used an empty string here but you could change this to whatever you want.