The Cunning Coder Blog

So I got into work yesterday and I realize I haven’t gotten a fax related to a lesson I have this week.  ”No worries,” I think to myself, “This teacher usually e-mails me plans so I best take a peek there.”  I go to open Outlook and I’m greeted by a rather unpleasant sight, “This program has stopped responding…”  Now, I’m not concerned yet.  Programs sometimes have hiccups, and this could just be one of those little oddities.

I go to open Outlook again, it instantly crashes.  Now I’m suspicious.  This isn’t normal behavior.  I start Google-ing around and find a myriad different things to try.  Start Outlook in Safe Mode, crash.  Try a new profile, crash.  Try a new Windows account, crash.  Run the Office Diagnostic Tool, no problems found.  With every option I explored I was no closer to finding a working solution.  Other mail clients worked fine, it was just Outlook that had the problem.  The only clue I gleaned from this search was that if I used a profile that had no e-mail accounts it worked, if I added my accounts back in the application died.  It was something related to fetching mail.

For some people, they’d probably just write this off and say “Well, don’t use Outlook.”  That’s a completely valid option, but now I have a mystery, and one that I want to solve if for no other reason than morbid curiosity.  When I got home after work I started thinking about it more.  Out of nowhere, I had an idea.  When I was playing with Outlook profiles I had noted that with no accounts, it wouldn’t crash, but with them it would.  Since there are 2 accounts in the profile, what would happen if I just added one back?

I plug in my cunningcoder.org details in the profile, crashed.  Not looking up, but I decide to see what would happen if just my old OSL account were used…  No crash.  Something about my cunningcoder.org e-mail was crashing Outlook but no other mail client.

I hop onto the control panel for my hosting and I notice they updated Dovecot while I was asleep.  Something must have gone wrong with the migration on my account.  I remote into the box and just as an experiment, I move the Mail/ folder to Mail.bak and then try to access my cunningcoder.org e-mail via Outlook.  No crash.  I copy my messages from the back-up back into the new Mail directory, no crash and all my messages are in tact.

I did lose the folder structure I had set up, but all my messages are still there and I have Outlook working again.  Definitely a weird ride, but at least I got all the way to the end.

Continuing along with my last post about trying to get Ichitaro to work I was really happy when AppLocale allowed me to use the application. But I noticed a new annoyance. Though I could manually start the application just fine, this doesn’t make sense for a document viewer. Most of the time you want to just double click the document and have it open, you don’t want to open the viewer, File -> Open and browse to the file you want to view. Though AppLocale will allow you create a desktop shortcut to open the program, it can ONLY be called on programs. I needed to find a way to make it behave slightly more normally.

After searching through the registry for a while I found the key responsible for the open command used for TaroView Documents. I’ll copy paste the relevant key below. Note, this requires that you have AppLocale and the Ichitaro Viewer installed in their default locations and this key was exported on Windows 7 professional.  Modifying the registry is potentially dangerous and I take no responsibility for the results of choosing to modify your own registry.  It will still nag you telling you that this is a “temporary” solution, but you can find a patched version of AppLoc.exe if you really want to get rid of that.

Below is the exported key that solved my problems.  It  will open anything that is registered as a TaroViewDocument to open through the AppLocale’d version instead of the default one.  I hope this helps someone else who was as frustrated as I was:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\TaroViewDocumentFile\Shell\Open\command]@="\"C:\\Windows\\AppPatch\\AppLoc.exe\" \"C:\\Program Files\\JustSystems\\TaroView\\TAROVIEW.EXE\" \"%1\" \"/L0411\" "

Ichitaro doesn’t like running on English Windows. I’m sure this is the same for virtually every other non-Japanese language setting but I finally had enough. I wanted to be finally be able to use MY computer to open the Ichitaro files I sometimes received from teachers and I was determined to get it to work.

I found that if I switched the non-Unicode language setting in Windows to Japanese it would work. Yay! BUT… This is a system wide change. No any non-Unicode program I have things it should be Japanese and that also messes with the display of certain things like the command prompt (which will use a Yen sign instead of a \). I could change it back when I was done, but each time you alter this system setting it requires a reboot. There must be a better way, I thought.

It turns out there IS a better way, but it’s still not perfect. There’s a program called Microsoft AppLocale (http://www.microsoft.com/globaldev/tools/apploc.mspx). This application will let you point it to an EXE and pick the language it should run it. It even will let you make a shortcut to always run the application through AppLocale. No reboots, not side effects. The only annoyance is that it doesn’t install properly under Windows 7 (You need to tell it to use backwards compatibility) and it will prompt you even when using a shortcut to remind you that AppLocale is just a “temporary solution”. Hopefully it’s right, and Microsoft will release a more robust system level update that will allow it to handle such situations on its own, or software manufacturers will start releasing software in Unicode.