Archive for February, 2010

Per-Database, Per-User and Overall Settings

Wednesday, February 24th, 2010

I’ve been doing some more thinking further to my previous post about changing DONATION to run not as an Administrator. In that post, I said that all of the settings that are currently stored in the Registry (in a place that can only be written by programs running as an Administrator) would move to a settings file in the new data directory for the program, which would be under the All Users Document folder, e.g. places like C:\Users\Public\Documents\Cooperstock Software\Donation, in Windows Vista or Windows 7.

My further thinking is that there are actually 3 different levels of setting that I’d like to store:

  • Overall settings for the whole program, e.g. for things like the location of the database file and the current database filename if you are using Database -> Switch Databases.
  • Per-database settings, like which donor and donation fields to display (which may be different if you have multiple databases, perhaps one for a church, and one not for a church).  These settings will come with you if you backup the database and restore it on another computer, unlike the other two levels of settings.
  • Per-user on that computer settings, like the user’s desired location and size for the program’s main window. (I know that it will be fairly rare for multiple users to be logging in to the same computer and all using DONATION, but it’s certainly possible.)

So, my plan is to have three places to store those things – an INI settings file in the new data directory, for the overall settings; a new hidden SETTINGS table in each database for the per-database settings; and the HKEY_CURRENT_USER area in the Windows Registry (which can be written by non-Administrators!) for the per-user settings.

Does that make sense so far? I will have some detailed documentation in the program of which settings are stored at which level, for those who are really interested.

Further, I’d like to run by you which specific settings I plan to put at which levels, to see whether any of you have counter-arguments for any of them. Here’s what I’m thinking. (You will note that some of these are settings that correspond to obvious things in the program, and others are things you may not have been aware I was storing anywhere.)

Overall Settings

  • Location and name (probably just the extension, since it MUST be named donation4.something) of the current database file.
  • Other database connection properties, like whether it’s a Standalone, Network Client or Network Server install.
  • Most of the settings from Maintenance -> Email Sending Configuration, except the From Name and From Email which may vary per database.
  • The contents of the mail-merge letter and receipt templates will be consistent across all databases (though you may choose to develop separate letters for separate databases). They will be stored in a Letters directory under the new data directory.
  • The list of databases you have in Database -> Switch Databases, if you use it. (It’s currently in a file databases.txt in the DONATION installation directory. That file will move to the new data directory.)
  • Whether or not you wish to be reminded monthly to check for updates to the program, and if so, the last date on which that check was done.
  • Your registration information, if you have used Help -> Register by Email. (Yes, you might have multiple databases/organizations, but from my standpoint if you are doing that from one computer, you should only have one registration record. You can put inform me separately of your additional organization names, or I will pick that up from your license key requests.)
  • The size of mailing label you use, and print margins for them if you change those margins.
  • The last folder you stored PDF files in.
  • The current version number of the program.

Per-Database Settings

  • The three optional passwords (Program Entry, Receipting, and Limited User). These are actually already stored in each database.
  • All settings from Maintenance -> Organization Info are already stored in each database.
  • All settings from Maintenance -> Receipt Options, including the Receipt Style For (e.g. Canada, USA, Quebec etc.). Believe it or not, I actually have at least two users with one database/organization in Canada, and another in the USA, so each database has to have its own settings for this. While some receipt options (like Location Issued) are probably really overall settings, I think it will be clearer for the users to leave them all as being per-database.
  • All settings from Maintenance -> Main Window Options. Again, if you have multiple databases, the way you store the data in each, and which Donor or Donation fields you want to see etc., may vary per database.
  • The From Name and From Email settings from Maintenance -> Email Sending Configuration.
  • Memorized settings from the Letters menu windows (like which type of letter you are currently using, its filename, etc.).
  • Memorized settings from Importing windows, like Database -> Import Donors and Database ->Import Donations, for which fields to import etc.
  • The last date on which you did a database backup, and location to which you did it, plus your desired backup reminder frequency.
  • The name and email address you send email backups to, if you use that feature.
  • Whether envelope printing should include your organization address and logo. (You might have pre-printed envelopes for one organization, but not for another.)
  • There will have to be a per-database place to store any bitmap files you use for the logo and signature for receipts. (This will be tricky for me to make the receipts use them in different locations – have to think on that!)
  • The settings for One Date Batch Entry (e.g. which fields to show, and whether to include existing donations).
  • The Subject and Body of the email to which the PDF receipts are attached if you use the option to email receipts.

Per-User Settings

  • Various menu options, like the Letters menu options, prompt you to read the Help on the relevant topics when you use those options for the first time. Whether or not you have used those options for the first time will be stored per-user, since each user will use them once for the first time!
  • The size and location of various windows in the program that are resizable and movable, which the program stores. (For instance, the main window, the Batch Entry window, and the Mail Merge editor window.) Each user might have their own preference about this.

Whew, that’s a lot of settings!

As usual, if you do have any comments, please Reply to this blog post, so we can all see them. Even if you just think this is all fine, a quick reply on the blog, or just by email, would really be appreciated, so I at least know some people have thought about this with me! Thanks.

Running DONATION as a non-Administrator

Friday, February 12th, 2010

One thing that isn’t ideal about DONATION, when run on Windows Vista or Windows 7, is that you have to run logged in as an Administrator. Not only that, but when it runs, if you have User Account Control (UAC) turned in Windows, which is the default, it prompts you as to whether it’s OK to let the program make changes to your computer every time it runs.

That’s really not how well-behaved programs are supposed to work, unless they absolutely have to have those Administrator rights. Until recently, I knew of no way to get around this, because if you use the Database -> Switch Databases menu option, it had to change an ODBC data source to do that, which could only be done as an Administrator.  Fortunately, I have figured out a way to run DONATION without needing to use ODBC data sources, so that problem goes away.

The Administrator privileges are also used, however, to allow DONATION to create and modify files under its own directory (normally C:\Program Files\Donation), because normally Windows will not allow non-Administrator programs to modify anything under C:\Program Files. Examples of files that are currently written there are your license key file, mail-merge letters and receipts, a file for tracking which database you are switched to if you use Database -> Switch Databases, and of course, your database file itself – donation4.db, in the Data subdirectory. If users want to supply a logo or signature bitmap file for the receipts, they have to be put into C:\Program Files\Donation as well, which is even harder, because the users have to do that with some other program, which means they have to explicitly run that other program as an Administrator.

To make all of this more “correct”, in Windows terms, I need to stop running DONATION as an Administrator, and move all of those changeable files under its directory to somewhere else that all users can write. My proposal is to use a subdirectory under the All Users Application Data directory. (This is one of Microsoft’s recommendations.) This would be:

  • “C:\Program Data\Cooperstock Software\Donation” on Windows Vista or Windows 7
  • “C:\Documents and Settings\All Users\Application Data\Cooperstock Software\Donation” on Windows XP
  • “C:\Windows\All Users\Application Data\Cooperstock Software\Donation” on Windows 2000

Unfortunately, there are some drawbacks to this change. The first is that it will be harder for users to find those files (including their database file!) if they are looking for them, and harder for me to even tell them where to look for them, since they are in different directories on different versions of Windows.

Another problem is that those are “hidden” directories, which you normally can’t even navigate to with My Computer, Computer, or Windows Explorer, unless you explicitly type in their names. You can only get to see those directories if you go to Tools -> Folder Options in one of those program, switch to the View tab, and check the radio button for “Show hidden files and folders”.

By the way, another change would be that many settings that the program stores, like various settings from Maintenance -> Main Window Options and Maintenance -> Receipt Options, which are currently stored in the Windows Registry, would now be stored in a text-based profile file in that folder mentioned above. This is because I want DONATION to work for any users logged on to the computer, and the Registry settings for all users can only be written by an Administrator. (I know that very few installations of DONATION are on computers with multiple users logging in to them with different logons, but it could certainly happen, and I think it’s best to make it work in that situation.) I may also move more of those settings into the database itself, mind you, which would be good, because they would come with you from computer to computer if you moved DONATION.

So, I’m asking for your opinions on my making this change. Except for not having to be prompted every time DONATION starts to say it’s OK, and for some new users, not having to obtain an Administrator Windows logon if they don’t already have one, there very little no real “win” in this change, and some real losses (harder to find those changeable files that were previously under C:\Program Files\DONATION).

What do you think? (As usual, please Reply via the blog, if it’s convenient.) Thank you.

Test version 3.23c – Non-Receiptable Categories, Custom Report date prompting

Tuesday, February 9th, 2010

Hello folks. I’ve just uploaded version 3.23c Beta1 to the www.software4nonprofits.com/pretest.htm page, for your testing enjoyment!

I’ve actually already uploaded the live version of 3.23b to the regular DOWNLOAD page, and I was going to announce that to all paid-up users today, but I got a brainstorm for a few new improvements yesterday, so I made those improvements, and am giving you a chance to test them before I announce version 3.23c to all users, probably on Thursday morning. (The users other than blog readers haven’t even been informed of version 3.23 yet either.)

The biggest change is the ability to have donation categories that are non-receiptable, by having their description be “Non-Receiptable” (duh!), or start with “NR ” or end with ” NR”, as in “NR General” or “General NR”. This means that by doing that, you can still use the Cheque # / Paid By field for its normal use (such as to enter a cheque number), for non-receiptable donations. The setting of donor categories to “Non-Receiptable” to mark an entire donor as always non-receiptable has also been enhanced by allowing ones starting with “NR ” or ending with ” NR”.

I had previously been asked about allowing the users to explicitly mark certain donation categories as non-receiptable, but I didn’t want to do that in a completely wide-open way (for any category text), because I was afraid they would forget which ones were and weren’t receiptable, and make mistakes in their receipts. Having it work by coded values like this, which should be pretty obvious, eliminates that concern.

The other really nice change is to Custom Reports, to allow them to be forced to prompt for either an individual date, a range of dates, or a range of dates and a donation category, just like some of the built-in reports do. This gives a lot more power and flexibility to Custom Reports.

As usual, please let me know any comments you have about these changes, or testing results (positive or negative!), preferably by adding a Reply to this blog posting.

The complete list of changes in this Beta version (which incorporates both 3.23b and 3.23c) are on the pretest.htm page that you can download it from, linked to above.

Thank you.