About maforshaw

maforshaw · ‎Jun 19, 2015

Hi Josh Many thanks for the hotfix, it works perfectly. Michael

maforshaw · ‎Jun 16, 2015

In the "Report File", generated from building a release, why is the "Source file" column now always empty? This worked fine in InstallShield 2014 and I use it to verify my files are being pulled from the correct location, due to various path variable replacements. In case it matters, my project is an InstallScript type.

maforshaw · ‎Oct 29, 2014

Hi SdFeatureTree uses a treeview so is the only one not affected and is why I concluded it affects all listviews. It's hard to tell from the dialog sampler without looking at every dialog but here are the ones I found so far that are broken: SdAskOptionsList SdFeatureDialog SdFeatureDialog2 SdFeatureDialogAdv SdFeatureMult Regards Michael

maforshaw · ‎Oct 29, 2014

Flexera Software already know about this bug, tracked as IOJ-1665102. All dialogs with check listboxes are broken if run on a Server OS. However, they cannot tell us if or when it will be fixed.

maforshaw · ‎Oct 27, 2014

What was the solution to this? The same fault exists on all server OS versions (e.g. Server 2003 etc.)

maforshaw · ‎Jul 25, 2014

JohnCresswell wrote: Work order IOJ-1663112 has been submitted to address this issue. As a work around can you try using lower case for any path variables that you intend to override. So in the example you give you would want to change VER_FOLDER to ver_folder in all places it is used. Please let me know if there are any issues with this work around. Hi John I edited the .ISM project file directly and did a search and replace to change my path variable overrides to lowercase (luckily they had more unique names than my example) and it seems to have worked, thank you. Regards Michael

maforshaw · ‎Jul 23, 2014

We have upgraded from 2013 to 2014 and now all our projects are building with the wrong files. The problem appears to be that Path Variable Overrides are not working properly if one path variable refers to another. Here is an example of path variables using an InstallScript project type: VER_FOLDER = 2013 X86_FILES = C:\Build Files\ \x86 X64_FILES = C:\Build Files\ \x64 If I set "VER_FOLDER" in the "Path Variable Overrides" section of the media to "2014", it still uses "2013" in the path variables "X86_FILES" and "X64_FILES" when built. It works fine if I directly override "X86_FILES" or "X64_FILES". However, the above is just an example; we have many more path variables that refer to VER_FOLDER. This worked fine in earlier versions so how do I resolve this?

maforshaw · ‎Feb 03, 2014

Did you ever get to the bottom of this? Does InstallShield 2013 work differently to previous versions on how it extracts files? We have the same issue with F-Secure Antivirus - it sees some of the ".tmp" files and blocks them with Access Denied. What InstallShield appears to be doing when it extracts/installs files is first give them a temporary name ending in .tmp and then renames them to the real name - is that correct and if so has this behaviour changed?

maforshaw · ‎Apr 22, 2013

Kelter wrote: I'm having this problem with IS2012 Spring. Has this seriously not been fixed in 4 whole years? I have dynamic links, I need to set the source directory at build time, and I expect documented features to work. I have spent a long time trying to get this to work, as documented, in IS2012 Spring. I then found this thread which says the ISCmdBld.exe "-l" switch does not work. Amazing that this bug still remains unfixed; I have logged a support case asking why.

maforshaw · ‎Sep 30, 2010

I also appreciate the explanation as the help file is not very good for this function. It needs to say when quotes are needed. This is especially important because of the way CreateProcess and ShellExecuteEx APIs work. If you are not careful, Windows will try to execute the first matching file on the command line as it parses each space. For this reason it always makes sense to use quotes when calling CreateProcess and ShellExecuteEx directly. We need to know (via the Help) if InstallShield's wrapper functions do this already. All my calls to LaunchAppAndWait and LaunchApplication first fully quote the filename. Based on the previous description I should now stop doing this. However, what about when using the LAAW_OPTION_USE_SHELLEXECUTE option? Do you also quote szProgram before defining the SHELLEXECUTEINFO structure? If not and we can't either because of the change directory issue, surely InstallShield need to clearly document that LaunchAppAndWait no longer works with the LAAW_OPTION_USE_SHELLEXECUTE option.

maforshaw · ‎Sep 30, 2010

The hotfix for this issue is the same file from a different issue (Q210954). However, the version stamp of the file from this thread is earlier (17.0.0.716). Does version 17.0.0.717 from hotfix Q210954 resolve BOTH issues?

maforshaw · ‎Aug 23, 2010

Hi Chirag Thanks, PM sent. Regards Michael

maforshaw · ‎Aug 20, 2010

Server wrote: We even switching from InstallScript and re-implement all installations to Basic MSI. I guess it depends how many installations you have to re-write and how much time. This is not an option for us.

maforshaw · ‎Aug 20, 2010

The release notes state that: In a future release, InstallShield will no longer be able to create or consume InstallScript objects, and no predefined InstallScript objects will be provided. It also looks like none of the provided objects have been updated for 2011. Is anyone else annoyed by this? I do not see Prerequisites as a complete replacement for InstallShield Objects. I have created lots of Objects for use with our InstallScript installations, the main reason being so that I can reuse shared code between them. Objects trigger many of the same events as the main installation so they are ideal for shared code. Since Objects can be associated with a Feature, I can also control if they are installed based on user selections which I believe is not possible with Prerequisites and InstallScript. Looks like we will be cancelling our maintenance contract.

maforshaw · ‎Apr 07, 2010

I think this is the same problem I had and InstallShield Support reproduced it. However, they are blaming a broken Windows API call in 64-bit Windows so see it as an enhancement request :rolleyes: The tracking number is #IOA-000054009 and may be resolved in some future version...

Online Status	Offline
Date Last Visited	‎May 26, 2021 12:15 PM

Re: Source File Path Missing

Source File Path Missing

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Path Variable Overrides Broken

Path Variable Overrides Broken

Re: Customers are getting .tmp access denied errors running Installshield 2013 installers

Re: Path Environment Variables - Recognition Trouble

Re: Issue using LaunchAppAndWait with LongPathToQuote in IS 2011

Re: IS 2011 Catastropic Failure when installing a feature

Re: Deprecation of InstallScript Objects

Re: Deprecation of InstallScript Objects

Deprecation of InstallScript Objects

Re: Short cut Icon fails on 32bit install on 64bit os

Re: Source File Path Missing

Source File Path Missing

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Compoent selection checkboxes are not coming in windows server 2008 R2 64-bit

Re: Path Variable Overrides Broken

Path Variable Overrides Broken

Re: Customers are getting .tmp access denied errors running Installshield 2013 installers

Re: Path Environment Variables - Recognition Trouble

Re: Issue using LaunchAppAndWait with LongPathToQuote in IS 2011