views:

385

answers:

5

I just noticed that some of my new Delphi controls get installed in the Public Documents folder in windows 7 (TMS Smooth controls and Virtual Treeview). Is there a reason for this, is this a convention or a few way of doing things or something that the operating system does.

Is there a place where I can set the root of my Source control to so that it integrates with RAD studio and windows 7 easier?

+4  A: 

When you compile a PAS file, the compiler will put a DCU file with the same name in the same directory. You can change this, but the default is to use the same directory. In Windows 7, writes to the Programs folder (and its subfolders) for non-elevated users can be virtualized. This means that when a program, like Delphi, attempts to write to one of these folders, the file will actually be written elsewhere, and may not be available the next time the program is run.

Therefore, since compiling the source files is something you do routinely, it makes sense to install them in a location which is writable by default, like Public Documents.

However, most component installers will allow you to choose a different install location. As long as you choose a folder which is not a subfolder of Programs, you should be OK.

Craig Stuntz
The IDE is themed, I believe, so the DCU files generated within the IDE cannot be virtualized. The controls BPL and DCP files should generally be installed in C:\Users\Public\Documents\RAD Studio\7.0\Bpl and Dcp folders, on windows 7. (Internationalized versions of Windows may use different folder names.)
Warren P
@Warren: 1) I think you mean manifested, not themed, but 2) you can override this and 3) `Users\Public\Documents` is the folder he's referring to in his question. That said, I don't think there's anything wrong with changing the default when need be.
Craig Stuntz
If you set the dcu output path of your project(s), the ide will not create the .dcus where the .pas files are but rather put them into the dcu output path. I think this is a good idea to do because it does not clutter the source directories and also prevents problems with different applications using different ifdefs.
dummzeuch
Yes, it is manifested, and when you want a manifest in your app, it becomes themed. So I guess the two are related in a transitive way.
Warren P
@dummzeuch, I agree. @Warren P, A manifested app will be themed if the manifest says to theme it. Teaming is an option; a manifest is a way of specifying options. The manifest and the options you choose are related, but not transitive. I do think that it's important to be precise here, as the details make all the difference in the world.
Craig Stuntz
+3  A: 

As for your "root of source control", Windows 7 does not require that you put it in any particular place, although some people may prefer to hold their source code in their user home folder (C:\Users[Your User Name]), I personally prefer to use something SHORT, like C:\DEV and this works great for me.

Warren P
That's the way we've traditionally done things. I know it's not required to be in any particular place, but if I'm on a small dev team and we can all expect our new components to install in the same place that really beats having to install them manually (to get windows registry values) delete them, and sync the library paths up with our source control.
Peter Turner
+1  A: 

Its really a matter of taste...just be wary of storing lots of data in your user directory... especially if your using roaming profiles, as this data will get shipped around to each machine you login to (and maintain a copy on the network). Good for backups, bad for login/logout times.

Since your using source control, for your projects, your better off creating a new directory off the root, and placing the source there. It won't be protected by UAC (other than initial directory creation of the first directory). I tend to create a C:\DEV directory on my machines, and then create subdirectories C:\DEV\3RDPARTY and C:\DEV\SANDBOX, all of my 3rd party components go into subdirectorys in C:\DEV\3RDPARTY and my "default" directory for Delphi points to the sandbox, where I create my "test" projects.

If your developing a 3rd party library for public consumption, then your going to want to use something like public documents, but give the user the ability to change the directory to match their preferences.

skamradt
Hooray for the C:\DEV tribe. That habit goes back to my early TurboPascal days.
Warren P
ever wondered why you see the C:\TP directory when some of the Delphi team members give presentations on conferences?
Jeroen Pluimers
+1  A: 

The folder you specified is probably part of the result of SHGetFolderLocation(CSIDL_COMMON_APPDATA) on Windows 7. It's what used to be the C:\Documents and Settings\All Users\Application Data on Windows XP, and is the proper location (according to MS) for application-related files that are applicable to all users of the computer.

Since I don't share my development machines with others, I usually install the components elsewhere (I have a secondary hard drive on my home machine and laptop, for instance, that I use for that kind of stuff). This prevents UAC issues on Vista and Win7 when the files are compiled or packages created, as I can safely give read/write access to everyone on that directory tree.

I use a separate folder on my work machine, off the root of C:\, called Comps. I install all of my third-party and inhouse components in subfolders of that one, which keeps them all in one place.

Ken White
+1  A: 

It was time that library writers stopped to write by default to . They prpbably choose public documents because Delphi itself puts compiled packages there, and because that's the only surely available writable directory which is not user-specific. I've being using for years a :\Dev\Lib directory with proper permission set where to store libraries, and :\Dev\Src for my projects sources (I like short paths). You don't tell which VCS you're using - many do not really need a single root, you can have multiple directory trees under source control, each with its own root. Anyway having a clear directory structure helps.

I usually keep BPLs in the same shared directory Delphi uses, because it is already in the path and avoids to "litter" the system32 folder. Unlucky many component writers still do not follow proper rules for library deployment, the most annoying issues I usually find are: - No separate folders for dcus (i.e. \dcu\D11), dcus are left in the source dir, no good when sharing a library across differend Delphi versions - Packages not using $LibrarySuffix to set the package version, but still putting it in the package source name - BPL left in the package directory and not in a directory in the path.

ldsandon
Agree 100%, I wish there were hints about that kind of stuff every time you compiled that couldn't be turned off. Because the net result is, it's never going to work when you copy your files off your computer.
Peter Turner