Category: Jessica’s Tech Blog

One of the things I’ve been finding most challenging as I develop PopTrayU is how to test and debug issues with emails. There’s no easy way to select an arbitrary email and paste in it’s raw headers to test the email.

Or just in general, situations like this: a user reports some bizarre error message that doesn’t make sense and is poorly worded about how dollar sign underscore isn’t an integer…they got this email from ebay.de that caused the error message. A little searching the code and google reveals the error message is probably caused by trying to convert a string to a number. Well, ok, so have a good suspicion of a couple places that might do this, such as where it’s converting dates around…but I need an email with the bad headers to cause this behavior… no easy way in. This bug has been around for some time (since before I started messing with the code), and it seems, in my opinion, that if it’s going to give an error message it should at least make sense, eg: “this email message is corrupt” and it should try to display the bad data as best it can excepting the corrupted header if it can’t be salvaged.

On the one hand, I could modify that code to try to fix the bug, but without creating a repeatable test-case, I have no way of verifying the fix actually fixes anything and isn’t just an incorrect stab in the dark.

As I think about how could I make the code more testable, I keep coming back to the need to break the code up into modular pieces, rather than a 7000+ line uMain.pas file. If I could break apart the pieces where it’s doing the message processing from the UI and input data source, I could make a second unit test project that fakes the input data and does something different with the output rather than display it on the UI.

So, now that I fixed the internationalization code so all my new labels are translatable (unrelated, but needed to be done), I think some refactoring will be my next sub-project…see if I can break down the mammoth main file into more bite-size chewable testable sections.

One area where PopTray/PopTrayU is currently less than perfect when it comes to Vista/Win7 functionality is that it stores the poptray.ini file (and other files such as rules and whitelist) in the program files folder with the application. In Vista and above, writing to program files when you’re running normal user applications is a big no no. Those kinds of files are supposed to go in a per-user folder under the users/appdata folder to support multi-user environments, and protect users from malicious applications overwriting things they shouldn’t. It doesn’t make my job as a developer easier, but from a security perspective, it definitely helps cut down on certain opportunities for viruses and trojans to be destructive.

But that leaves me with a dilemma. The old design where everything was in the same folder, and the app doesn’t use the registry makes copying the app to a memory stick to use on other machines (say, internet cafe) with locked down machines pretty easy and doesn’t require an installer. Also makes side-by-side use with PopTray easy, since you can just plop poptrayu.exe in the PopTray folder and go.

But, with Vista/Win7, that model where everything goes in the app folder makes a lot of headaches for users who accidentally ended up with a virtual program files folder and can’t figure out why their changes aren’t “sticking” to poptray.ini or the plugins they are trying to install are suddenly “missing” and they have to approve all these UAC prompts to even install a plugin. Not the best of user experiences.

In order to support Vista/Win7 properly, the default storage location for those files needs to be appdata (aka a user-specific folder). I’ve been debating whether it would be best to keep things simple–now poptray.ini HAS to go in user/appdata/roaming/poptrayu/ unless they specify otherwise by using the command line options to specify the “ini folder”, or whether to come up with some more elaborate scheme such as falling back to the app directory if the user/appdata/roaming/poptrayu/ folder doesn’t exist.

Then, if I change the default storage location, there’s another ball of worms, as far as updating the installer to move/copy the ini file to the new storage location, whether it should import the ini file from poptray and/or poptrayu’s app folder if it’s there, etc.

So, please discuss in the comments, what you think the “right” behavior of the app should be. Do you actually use the use-case where having fall-back folders would be handy, or do you just run the installer and expect it’s going to magically put everything in the right place and you don’t care where it is so long as it works?

About a week ago, I uploaded the first completed beta version of PopTrayU up onto Sourceforge. I sent a link to Renier to test/comment, and he sent me back some comments about some bugs–mostly minor stuff to fix, like an incorrect link to the help file. But a couple are bigger/trickier issues.

In particular, one is the issues with storing user-editable files in Program Files under Vista/Win7… well, you can, but it can cause quirky issues, like “virtual”/duplicate files to be created depending on the security settings, and that can cause it to look like there’s bugs in the app when there isn’t. On the one hand, having everything in the app’s directory is nice because you can run it off a memory stick with no installing required, on the other…well, trying to cooperate better with the OS can be a boon and not confuse users… 😉

I’m still contemplating the best way to fix that. How should the app decide where the default ini file storage goes? Should it always be in the appdata/user folder? Should it look in the user folder and if that folder doesn’t exist, fall back to the app folder? Use a registry key to store where the config files are? Make the ini file only have one line that points to the location of the “real” config file.

This problem doesn’t stop at just an ini file though. (and as an aside I’m not going to get into the holy war about “outdated” ini files vs “non-portable” registry entries at the moment), For PopTrayU, files the user might be more interested in editing than an INI file (no need to edit that one manually) would be to install plugins, sounds, or the skin files. So ideally, that should be in a user writable folder without needing to use UAC dialogs or administrator permissions, so not in program files. Maybe I need to explore how other open source software that have similar support files (Miranda IM comes to mind) have dealt with changes to OS restrictions on newer versions of Windows.

The second bigger one is a bug more than a design issue. Use the SSL plugin to connect to Gmail, and bam, get an access violation memory error. I was actually able to reproduce this the first time I set up my gmail account and accessed it. But then I turned break on exceptions back on and restarted the app, and it wouldn’t reproduce anymore, and additional testing of using my gmail account since has not reproduced the issue. So this one is going to be tricky to fix because I’m not sure what causes it. I guess I’ll have to keep my eyes out for additional hints on what factors are necessary to reproduce the bug.

Today I got an email from a sourceforge user thanking me for continuing the development of PopTray and letting me know about an issue the user was having with custom sound notifications, an area I haven’t thoroughly tested (nor made changes to). You mean people are actually using and finding my app even though I haven’t done a lick of promotion (aside from creating it’s sourceforge page) yet? Awesome. I kind of purposely haven’t been promoting the site yet, as I’d rather have bugs trickle in than flood in, so I have time to look at them and fix them rather than just queuing piles of duplicate bugs. That’s why you do beta versions, right? You want enough exposure to find the bugs, but not so much that you’re overwhelmed with duplicated feedback.

Yesterday I logged onto Sourceforge account and created a project for PopTrayU, so I’d have somewhere to release my modified PopTray. Yes, I could probably do it all from scratch on my own site, but why bother when they have all the tools right there, it’s a respected site for looking for free software, and it’s also where PopTray’s verison history is hosted as well.

For some reason I had presumed that Sourceforge only provided hosting for files and I’d have to zip up complete versions of source code to save on Sourceforge (probably because that’s what PopTray did), but lo and behold, it has options to set up SVN or Mercurial. I wish I’d known about this sooner!

I’d previously looked into setting up SVN on my website for this purpose, but although creating the repository worked flawlessly without installing any additional tools, figuring out the username/password issues and proper URL repository path on the shared hosting environment was not successful. So I had been doing daily zip file backups every time I work on the project up until now with the hope that I would eventually get real version control set up where you can browse all the incremental changes to each file to track where a change was introduced, etc.

Now I am chugging away at setting up the repository structure, and going back to the original source code, checking that in, and checking in incremental bits of the changes in managable chunks. It may or may not compile on any of the intermediate versions because I’m mass importing changes via diff’s, but it’s a small price to pay, I’ll probably add a tag when I get to the point where I have something checked in that builds and compiles. Mostly I’m checking in incrementally so I can better document what changes I’ve made and isolate related changes in case any of them later need reverting or debugging…slightly more useful than here’s every change that’s in version 4.0

It just feels really good to get everything checked in, so I have a good, easy, up to date, not on my computer backup of everything, so there’s less risk of having to start over if my hard drive explodes.