InstallFolder variable is overwritten


If I use the bafunctions.dll (to support the DelayStart), the InstallFolder variable is overwritten (not the value I set the variable to) when displaying it in the Options dialog.

Example 11 in the distribution demonstrates this behavior, and in the install logs you can see the variable getting set to what I set it to, and then later it is reset.


nsleightholm wrote Dec 6, 2013 at 9:51 AM

The sample baFunction includes code to change the install folder, removing this should solve the problem.

wdh61 wrote Dec 6, 2013 at 12:54 PM

Yeah, I saw that an was going to give it a try. The problem I'm having is the solution/projects are MS Visual C 2012. I have version 2005. Trying to get it to build is problematic.

wdh61 wrote Dec 6, 2013 at 2:21 PM

The workaround is to use InstallFolder2 until you can get this fixed. Probably shouldn't set InstallFolder as an example......

nsleightholm wrote Dec 8, 2013 at 4:47 PM

This isn't something to fix as it isn't a bug, the code is just a sample for you to customize. The DelayStart function is anything useful, again it it just something to show how to use it.

wdh61 wrote Dec 8, 2013 at 9:14 PM

The only reason it's a problem for me is I can't rebuild the dll. I don't have MSVC 2012. I contend this is a bug since it was compiled and distributed as a binary without a way to turn it off by configuration.

nsleightholm wrote Dec 9, 2013 at 7:04 AM

It isn't a bug as it is sample code that would never be used in a real world situation. To rebuild be the code in VS2005 just create a new DLL and add the source from the sample to it - if you have the SDK installed you might not even need to do that as the batch file might work (MS shipped the C compiler with some versions of the SDK).

wdh61 wrote Dec 9, 2013 at 2:07 PM

I tried both that batch file build, and "creating a new DLL". No joy. I didn't spend too much time chasing down the unresolved externals, file references it couldn't find etc. I just don't have the time; I have my own project to finish.

Since this code is, by your own admission, "sample code that would never be used in a real world situation", why not disable it, or allow a variable that disables it in the next release?

For now, I'll use the workaround of InstallFolder2.

nsleightholm wrote Dec 9, 2013 at 6:00 PM

I am obviously missing the point why are you using this DLL at all? It just demonstrates the features you use, there is no reason to include it at all, none of the code in it is useful in a real world installer.