Hi Naoto. After a discussion with my client, we decided a hidden folder was OK. No backups are performed on these computers. Most of the computers are running in a scale shack with touch screen monitors so the truck drivers can weigh in their own truck.
Thanks.
>Is there any particular reason why it's a problem if the folder in which the ini folder resides is hidden? If it's for backup purposes, shouldn't you be able to configure the backup application to scan that folder?
>
>>Thanks Dragan.
>>
>>I can't use the program files directory any more because of the security restrictions in windows 7. My client is a major corporation and likes to standardize their installs and I was trying to come up a new location that makes since. I wanted to use built in constants because they still have a few xp computers and Inno does change the location in that case. The only other location that makes since would be the {commondocs) folder but I have a problem installing a program in the docs folders. The {commonappdata} seemed to be the logical location but that folder is hidden. I my have to just hard code a location and go with that.
>>
>>
>>
>>
>>>>Hi All,
>>>>
>>>>I am using Inno Setup to build my installs and it is working great. One issue I have is which constant to use for the install directory. My app uses a sql database and I only need to write to an ini file and a couple of logging dbfs. I started using the {commonappdata} constant but on Windows 7 it uses the programData directory which is hidden and I am getting some push back from my customer. I was curious what others use?
>>>
>>>I'd recommend that you let the user install wherever they want, and save that location for the upgrades.
>>>
>>>Two reasons for this:
>>>
>>>1. many machines are made with a C: partition of insufficient size. Lots of apps, specially various demos, evaluation versions etc don't give the user a choice of location, so the C: drive gets cluttered. I prefer to install my apps on any other partition, even though nowadays I have almost a terabyte free space (and 80 out of 130G on C:), just because the Windowses themselves tend to eat space over time, and I really hate to deal with support calls when the machine is stuck with no temp space left.
>>>
>>>Also, because the Windowses will probably crash and have to be reinstalled about once every few years. Probably because we're programmers, not regular users. It may be due to anything - a faulty driver, a brownout which causes a fault in the filesystem, a rootkit, an app which hits a rare Windows bug, whatever. I just don't want to lose everything when that happens - and, believe it or not, about 80% of apps I use don't give a damn about proper installation and registry. Reinstall Windows and just run them apps from where they are, and they'll be just fine. Most of them know how to reestablish file associations etc even without registry, so it's basically only Microsoft stuff that MUST be reinstalled, the rest generally works.
>>>
>>>2. When the update comes, it should just plain KNOW where the previous version was, and offer that as the location. It should not lose any of user's settings.
>>>
>>>In InnoSetup, the UsePreviousAppDir is true by default, so it covers the 2nd requirement. As for the first,
>>>
DefaultDirName={pf}\My Program>>>would put you below the "Program files", but that's only the starting point for the user, and I actually like to let them install wherever they want.
>>>
>>>With the changes in the Vista and later, I tend to keep user's local settings somewhere in their application data, and everything else on the SQL. No common folder where every user would write, and again no scattering of folders. I've seen apps which install in one folder, keep their settings in another, and users profiles in subfolders of that or in user's appdata. Which then makes it near impossible to find things - it doesn't explicitly tell you what's gone where during the install.
>>>
>>>(obviously, I'm re-reading Alan Cooper these days :)
