DONATION 3.31 Beta6: PDF Printer Fixes

August 1st, 2010

Hello again DONATION beta testers. Well, the new PDF printer in version 3.31 Beta3 that I informed you of recently worked for many people, but not for everyone. Some users, particularly those with Windows 7 and/or 64-bit computers (I think!) still had problems.

It turns out that the issue is that for some of those users, the Save PDF button on reports and built-in receipts (but not mail-merge letters and receipts) fails if the program is not run as a Windows Administrator. And I changed the program to stop running as an Administrator in version 3.30, to better follow Microsoft guidelines, and to stop those annoying User Account Control “Is it OK for this program to modify your computer?” prompts for users with Windows Vista or Windows 7.

The solution I ended up with (which I am not completely happy with, but can’t see how to improve on at this point) is that if you run DONATION normally (not as an Administrator), try Save PDF, and it fails, you get a message to re-run DONATION as an Administrator, re-do the action you just did, and do Save PDF from there.

Another option that does work, oddly, is instead of using Save PDF on those reports or built-in receipts, use the normal Print button, and in the printer dialog box that comes up, switch to the PDF printer, “novaPDF Pro v7 for DONATION”. N.B. for receipts, there is no printer dialog box, so you have to pre-select that printer using the Print Setup button before clicking Print. When you do this, you get novaPDF’s dialog box prompting for the filename to save the PDF file to, without the default paths and filenames that Save PDF prompts you with (in my dialog box), but it does work, even without running as Administrator.

If this all seems a bit mysterious to you (why some things work and some don’t). it is mysterious to me as well! That’s because it’s about how the novaPDF software (that I bought) works, which is out of my control. I have worked with their tech support folks on this, but haven’t received any better solution.

Anyways, if you could try this out (at http://www.software4nonprofits.com/pretest.htm as usual) prior to my releasing it to the main web site, that would be great. As usual, please let me know any testing results (positive or negative!) via  a Reply to this blog posting.

I don’t plan to email all users about the release of version 3.31 after I release it, because it just isn’t major enough to warrant that. Rather, I will inform any users about it who write to me about having problems with PDF printing. And of course, all new users will get this version.

Thank you.

DONATION 3.31 Beta3: New PDF Printer

July 17th, 2010

Hello DONATION beta testers. I have a new version for you to take a look at, if you have a few minutes. As usual, you can get it from www.software4nonprofits.com/pretest.htm.

Here is what is included in version 3.31 so far, in rough order of importance:

  • Changed the saving to PDF files so that it doesn’t encrypt/protect the PDF file from modification unless it is a receipt or is a statement being emailed to donors. (Previously all PDF files created by DONATION were encrypted.) This may solve a problem that a few users are having where PDF printing doesn’t work.
  • The program now uses a new version of the novaPDF PDF-printing software (version 7.1 instead of version 5.5), which may solve a problem that a few users are having where PDF printing doesn’t work.
  • Fixed a bug, where if you logged in to DONATION using the Limited User Password, and you backed up the database, you received an error message after that, and the program exited. (You could start it again after that, and the backup was successful.)
  • Now if you are using the Limited User Password, you can no longer use the Database -> Switch Databases menu option. (It could cause complicated problems, that would have been hard to fix, and seems very unlikely to be required by limited users.)
  • Fixed a bug where you use Maintenance -> Change Year -> Previous Year, and the default date for new donations stays as the last date used in the year you just switched from, allowing you to save donations with a date in the wrong year. (If you used that menu option several times in a row, you could even end up saving donations with a date several years forward.)
  • Made a small fix that may prevent a crash during mail merges that one user was experiencing, with the message “Null object reference at line 3 in function of_focus of object u_web_browser”.

The change to the new novaPDF printer version is the most drastic change in this version, and the one I am most concerned about being tested. (To test it, after installation, just run any report, then use Save PDF and make sure the PDF file gets created and displayed to you.)

As usual, please let me know any testing results, postive or negative, preferably by adding a Comment to this posting.

I’d also like your advice about whether I should inform all users of this new version, or save it up for inclusion with the next version that has more significant feature changes. Of course, I would upload it to the normal web site once I’m sure it is OK, and I would inform any users who are having problems with the PDF printing that they should upgrade to this new version. But I did inform all users of version 3.30 just last month, and I don’t want to overwhelm everyone with too many upgrades. What do you think?

Thank you!

DONATION 3.30 Beta4: Edit the Paid By List

June 7th, 2010

I have just released version 3.30 Beta4 to the www.software4nonprofits.com/pretest.htm page. It has one improvement, that people have been asking for, for a while:

  • You can now edit the list of Paid By values for the Cheque # / Paid By field’s drop-down list for the Donations, by using a new Maintenance -> Donation Paid By Values menu option.

I’m thinking that the full version 3.30 will be released, initially to paid-up users, either this Thursday or next Tuesday, depending on a few issues.

As always, any comments will be appreciated.

DONATION 3.30 Beta3 – Emailing Statements

June 2nd, 2010

I have released a further beta version of the new version 3.30, with the following two changes:

  • All “statement” reports and mail merges can now be sent by email to donors who have email addresses, just like the receipts. This includes Reports -> Donation -> Details, One Page per Donor and Category Totals, One Page per Donor, and Total Donations information mail merges. See the Help topics Statements and Receipts and Emailing Receipts and Statements for details.
  • This change was actually in Beta1, but I forgot to mention it!) The program is now much more flexible about the names and locations of logo and signature bitmap files for your receipts and letters, allowing you to select them on a window you reach from the Maintenance -> Receipt Options window, and allowing them to have any name and standard bitmap filename extension (e.g. BMP, GIF or JPG). Also, you can specify different logo and signature bitmaps for different organizations/databases, if you have multiple databases on the same computer.

As usual, you can download the beta version from http://www.software4nonprofits.com/pretest.htm.

If you try version a beta of version 3.30 at all, please let me know, even if all you do is confirm that it installs correctly. And of course, if you do have any testing comments, please add them as a Reply to the blog post.

Thank you.

Beta test version 3.30: Running as non-Administrator

May 31st, 2010

Hello again DONATION beta testers. I finally have at least an initial pretest of the next release (3.30) available. Because in some ways this is a fairly major release, I have bumped up the version number from 3.23j to 3.30, instead of just going to 3.24.

This version consists mostly of the changes discussed in my two previous blog postings, Running DONATION as a Non-Administrator, and Per-Database, Per-User and Overall Settings.

This is an odd release in a way, because on the one hand, I had to make a huge number of changes to the program internally, and to the installation program, in order to achieve the changes discussed in those blog postings (and in the detailed list below). But on the other hand, the perceived value for users is fairly slight (mostly Windows Vista and Windows 7 users not having to click a button to allow the program to run as an Administrator). Fortunately, there are also some additional small improvements, bug fixes etc.

For testing this, I need at least some of you to install it as an upgrade to (i.e. on top of) your current installation, because some of what has changed is the location of many files, and thus the installation program has to move these files. If I got something wrong, which my own testing didn’t show up, this could cause problems. I will of course make myself as available as I can to solve any such problems that come up, ASAP, either by immediately fixing them on your computer for you (via a remote control session if necessary) or with a quick new release of the beta version that fixes it.

Having said that, testing the new version as a new install on a different computer would also be helpful.

Here is the complete list of the changes in this version:

  • Made a lot of small changes to allow the program to not require being run with Windows Administrator privileges on Windows Vista, Windows 7 or other versions of Windows with Microsoft’s User Account Control feature in them. This saves on having to click on a User Account Control “Allow” button to allow it to run, every time you start it, and better conforms to Microsoft guidelines for applications. (It also no longer requires being run as an Administrator on Windows XP.)
  • Among other changes required for the point above, moved a lot of data files from various places under the standard installation folder (usually C:\Program Files\Donation) to a new data directory that is not under C:\Program Files (where non-Administrator programs may not modify files).
  • Also among those changes, the program now stores it settings in various different places. Many settings, such as those in Maintenance -> Main Window Options, are now stored in the database, which means they go with it when the database is backed up from one computer and restored on another. It also means that if you have two databases for two organizations, they can have independent settings on that window.
  • In the windows for Letters -> One Letter and Letters -> Mass Mailing, removed the final sections for specifying whether or not to use a standard save pathname for the merged file, and for specifying an alternate save pathname if you aren’t using the standard one, and for editing a previously saved merged file. Those sections were just confusing and not particularly useful. Now the standard save pathname (the letter file name with “_save” added before the “.htm” extension) is always used.
  • Also in the mail merge windows, added a new OutstandingAmount field to the Donor Information and Total Donations Information merge options, which is filled in with the donor’s annual Pledge amount (or 0, if there is no pledge) minus the Total Amount donated.
  • Created a new Tools menu, with new options Explore Data Directory (which opens a Windows Explorer window in the new data directory) and View Saved Settings (which displays all settings saved by the program, and where they are stored).
  • Moved the Help -> Register by Email menu option to the new Tools menu.
  • Made a number of small improvements to the installation program. In particular, if the program has been copied to a new computer (instead of installed there properly, as explained in the Help topic Move the Program from One Computer to Another), it now offers an option to delete and recreate the license file if the current license key is out of date, which previously would have prevented the install from completing.
  • Fixed a small typo in the French and bilingual receipts: “d’enterprise” was corrected to be “d’entreprise”.
  • Renamed Help -> DONATION on the Web to Help -> Software4Nonprofits Web Site, for clarity.
  • Changed the installation program to always write a log file C:\Windows\DONATIONSetupLog.txt, which can be used to diagnose any problems that come up during an installation.
  • Fixed a bug in Reports -> Custom Report, where if you picked Sum(Total Amount) or Sum(Eligible Amount), or both, and also at least one of the Receipt fields, it generated incorrect SQL that gave an error message when you tried to run it.
  • Added a new Help topic, Pledges in DONATION, to explain various aspects and limitations of using pledges in the program.
  • Fixed a bug in Reports -> Donation -> Details, One Page per Donor, where donations that had longish Descriptions could have part of those descriptions cut off at the right.

As usual, you get the beta test version from the page http://www.software4nonprofits.com/pretest.htm. You will see that versions of all of the installation programs are available there. For most of you, all you will need is to use the first option on that page, the update installer donupdtBeta.exe.  It will upgrade anything except for a Lite version to be version 3.30 Beta1. But if you want to try any of the other installers (the Lite version update, full Lite version, full Standalone installer, full Network Server or full Network Client) that would be great too. You can easily switch between the various versions (Standalone, Lite, and the two Network versions) by just running the appropriate installer.

Thank you so much in advance for any testing you can do on this, which will help prevent me from releasing any bugs to the thousands of other users. Of course, as well as reporting any bugs, I would very much appreciate any comments you have about the changes, once you have played with them. As usual, the best way to comment on anything you note is to Reply to this blog posting. But emails are fine too!

Mail merge bug – need help diagnosing!

April 2nd, 2010

Two users yesterday informed me that they were observing a bug in Letters -> One Letter (and perhaps also in Letters -> Mass Mailing, they didn’t say), which I cannot reproduce, so I’d really appreciate your help with it.

The bug is that the mail merge field <<today>>, which should get translated to today’s date in your normal computer’s long date format (usually things like “April 2, 2010″), instead prints as “January 1, 1900″.

I’m assuming this only happens in fairly restricted circumstances, or I would have had a lot more reports of it by now, but I have examined the program code related to that field and so far I really can’t guess how or when it would happen.

If you could try just any letter in Letters -> One Letter, e.g. the one where you select “Donor Information only” in section 1, and just use my default letter, or whatever you have modified that to, if you have modified it, and see whether the date comes out OK, I would really appreciate it. Let me know if it comes out as “January 1, 1900″ (or anything else that is incorrect!) and then I may ask you to do some further diagnosis.

Thank you very much!

Oh, and for those of you for whom this is meaningful, Happy Easter! (It will be a happier one for me if I figure out this bug and get a fix out for it.)

OK to remove confusing mail-merge options?

March 24th, 2010

There is part of the Letters -> One Letter and Letters -> Mass Mailing windows that I suspect is very little used, and can be confusing.

That part is Section 3 in Letters -> One Letter and Section 5 in Letters -> Mass Mailing: the parts where you can specify the name of the file in which to save the merged letters, and whether or not to use a standard filename.

My impression is that first, there is very little reason to use this to review previous merges – you can always just re-merge a letter or letters instead. And it just adds to the confusion.

The only reason to pick a different (non-standard) filename for the merged letter(s) is if you want to keep old merges on file, each with its own name. But that also is going to become very confusing, and if you really want copies, you could print them instead.

Does any one reading this use those options, or think I should keep them in the program? Please let me know by writing a Reply to this blog. And if you don’t use them or see a reason to keep them, a quick reply to let me know you’ve thought about it would also be great! Thank you.

Church IT Roundtable Survey

March 15th, 2010

Tony Dye, of the Church IT (Information Technology) Rountable and ChMS (Church Management Software) Google Group, is doing a small survey on church management software used by churches.

While DONATION is certainly not a full church management software solution, a lot of DONATION users in churches use it instead of one, because they don’t need all of the other features of a fuller ChMS solution.

If you would be willing to participate in Tony’s survey, either by filling in a short set of questions, or letting him interview you by phone for 5-10 minutes, you can find it at:

http://groups.google.com/group/chms/browse_thread/thread/e19af09f92d7d073

Thanks.

Per-Database, Per-User and Overall Settings

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

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.