I think it depends on how flexible you want it. I wrote a class that stores, retrieves, and serializes options (something I wrote to help me learn .NET that works in any application I write), and I store the config data using that in the same folder as the application (actually, a subfolder named for the user who's using the config options). Using that, the program can be moved at will to anyplace on the hard drive. The only problem with the Registry that I can think of is that if you're storing paths, moving a program to another drive/folder would have to entail Registry changes and wouild probably be a bit on the annoying side. Also, if I remember correctly, the Registry isn't the place for large amounts of information -- I want to say something like >2k should be stored in .INI files or somesuch.
As for the Application Settings folder, that is a good idea. It insures that the application would always know where the data it needs is, but if you're storing a lot of data it could be problematic for people who put their OS on small partitions and their applications on the larger ones.
large is a relative term. The total amount of data per user could be no more than 500K excluding downloaded entries. That can go in the Application Data Folder without problems. Uh, for downloaded entries, I plan on saving images in them too, so it could get large really fast. I guess the best thing for me to do would be to add an option as to where to save downloaded entries. Seems like a good idea.
2002-07-28 05:32 pm (UTC)
I'm one of those people, but I have Windows configured to put my "home directory" on my large partition with the rest of my data. I'd hope that anyone else savvy enough to make partitions would have either done that or used NTFS's capability to mount one partition into the filesystem of another.
Anyone who hasn't made arrangements for this must get problems like this frequently, and it's their own fault really. I'd say put it in the directory Windows provides for that purpose, as it makes it easy for users to ship their settings around and back them up without taking with them applications that they could re-aquire relatively easily.
I know how to do the former (configure where Windows puts a user's home directory). However, I've heard of the latter (mounting a partition into the filesystem of another), but have no idea how to do it. Do you have a handy link explaining it or something? I'm curious.
I don't have links, but you do it from the
Control Panel > Administrative Tools > Computer Management > Storage > Disk Management
When you make a NTFS partion, you can select where it mounts.
This is for win2k/XP Pro, I'm not sure about NT or XP home.
2002-07-30 02:51 pm (UTC)
Oh, you have to do it when making the partition itself? Heh. I hadn't realized that.
Well, you don't have to do it when making the partition, but both partitions must be NTFS(or at least the one that will be a mounting point for the other one, I'm not sure if you can mount FAT32 on NTFS).
2002-07-30 10:03 pm (UTC)
Well, okay. I already have the two NTFS partitions. Just I have no idea where I mount D into C somewhere. (I don't know where menu-wise)
I'd vote for an XML file in some form. This would allow someone to easily move all settings/data between installations of the client. Having it in the client's directory might not be possible because of permissions and nonadministrative users.
You could probably just create an abstract interface to your data, (a node tree for each user, for example). The interface would know where to put each node of data (for example, user login/state info could be stored on the HKLU\ tree, while user icons and whatnot would be stored on disk in a user-specified folder as XML). The key is your program works with the interface and need not worry about where each piece of data is going exactly. Of course, you'd have to figure out how the interface would know where to put data, but that's another story.
Either way, with the user login data and what-not in the registry, your program need not worry where to find its config data when that particular user logs in, and also need not worry about putting stuff in the Application Data folder. With the user icons, entries, etc. being stored somewhere user-configurable, you could offer the Application Data folder as default, and if the user is not satisfied with that, he/she can move it someplace else. Just store the user folder in the registry with the other data.
Well, at least thats how I'd do it. ::sheepish grin::
I like your idea the best. And I am going to implement it, but I'm not going to build the interface right away, that'll be reserved for a later beta. I want it to work first. Thanks :)
2002-07-27 10:09 am (UTC)
On NT+ systems, only the registry protects data from other users if they aren't running NTFS.
You should read the docs on the registry. They say what belogs there and what doesn't.
And it's kinda sad that a journalling client would depend on alpha-blending.
To be honest, the alpha blending is there for the precise reason I don't want to support 9x/ME. Very few 'power-users' actually would use 9x anyway, which is my target audience. And plus, alpha-blending is a nifty feature to have when you're writing a WYSIWYG editor. I could probably do without it, but it just makes my life as the programmer easier. Maybe someone will write a port, it would take a few hours max.
Why do you need to store the login response hashtable? You can regenerate that on every login.
Also, from a UI perspective, MDI is a PITA... I might suggest SMDI/MSDI instead (multiple independent parent windows).
I agree that multiple parent windows would be a great idea, and I am working towards that, but its low on the list of priorities. I'll have a working MDI interface first because its very easy to program in .NET ... Once the backbone is in place, I can refine the interface.
Thanks for all your input, if you have something that hasn't been said yet, please leave a comment.
So far it looks like I'll do the following.
I'll store paths for config files and downloaded files in the registry. They will default to the application data folder, but the user can set them in preferences. =) ... If I feel ambitious, I'll write a wrapper for this, make it a little more transparent.
Thanks for your ideas everyone.