So in Visual Studio 2008, I got a GPF in the code that loads the toolbar information from the registry. It turns out that they have an assertion if a particular pointer is NULL, which is good. The assertion has been there for a very long time.

It would be better if they then NULL-tested the pointer before proceeding to use it in the new code below.

Of course, given that we just tripped over a NULL pointer bug in my own code, I suppose I shouldn't laugh too loud.

I did file a bug report.

Supposedly, the modern versions of Windows have lots and lots of resources available. It was, thus, with some disappointment that I discovered that there appears to be a limit on how many menus an application can open. The CMenu::LoadMenu call in MFC returns a NULL pointer (which I did cleverly check for), but when you call GetLastError to find out why you failed, the answer is an uninformative value of "0".

Isn't that special?

I was looking for some info on a bug that I'm working on, so I headed off to Google and put my search string together to see what I could find.

I was quite disconcerted to find that my blog here was the number five result on the list. :)

"No, no. I'm looking for what other people know about this problem!"

It turns out that Windows Vista has a bug that prevents you from opening and saving a compound document file back to the same name unless you're logged in as an administrator on the machine. There's a hotfix available, which is good. The fix isn't in Vista SP1, which isn't.

Obviously no one at Microsoft tested this on anything earlier than the 2007 versions of MS Office, since all the earlier versions use compound document files for storage. Or else they never logged in without administrator rights.

Security. Gotta love it.

Ok, I finally found the appropriate documentation for using MSXML with C++. You'd think this stuff would be easier to find...

I'm fighting through using MSXML 6.0 right now and concluding that Microsoft really, really wants everyone to be using C# for this. Or maybe Visual Basic. Nevertheless, I'm doing it in C++ and the pain is tremendous.

I suspect it will get better later this week once I get done building the utilities that Microsoft doesn't seem to supply.

It is when you are desperately trying to finish up your bugs so that you can go home that Microsoft Visual Studio will decide to crash.

Twice.

So far.

I should be on my way home for dinner with daisy_knotwise, her brother Jeff, and his wife Carol. But since the VPN into the client's network doesn't always let me talk to the printer and it's working for me at the moment and I think I found the problem, I'm trying one more test. One more very slow test.

It looks like calling ResetDC( m_hDC, NULL ) is supported by many printer drivers. Apparently not by the ones from Sharp. Oh, joy.

After considerable thrashing about, I've determined that Microsoft's setlocale() function caches the current user locale so it doesn't look it up again if you go and change it in the Control Panel while an application is running. I now know how to assemble the correct locale string and pass it to setlocale() so that the locale is changed correctly, but this is completely undocumented.

gack

I hate days like this. I spent all day (and several hours yesterday) trying to debug an application that appears to be corrupting the OLE clipboard. This has been made nearly impossible by the fact that the debugger keeps hanging up.

In a burst of inspiration, I ran the debugger on the debugger and hit break. It turns out that the copy of Codewright for .NET that I installed into Visual Studio is trying to find out what's on the clipboard. But since the clipboard is a steaming pile of entrails (see tonight's CSI for more), it fails. Over and over again. Although it certainly doesn't use much CPU while doing so...

Tomorrow, I find a machine without Codewright and try again.

So this old piece of code I'm maintaining calls OleSetClipboard and hangs. There's what I needed to make my day complete.

At least, I think this will get it back inside its banks. In the process of revising some of the code, a derived class opened a file using CStdioFile and closed it using CFile. Oops! Hilarity ensued.

I'm currently cleaning up the thread handling in our Server app. Now, if I can just figure out why the stream handle table is filling up. (It only holds 51,200 streams, so obviously that's not a problem.)

I just typed up an eight-page document that contains all of the changes that I think we should make to our serialization scheme here at work. I think I'll go home now...

As in, "You are lost in a maze of twisty passages, all alike."

I'm trying to port some code from a 3rd party OCX up to VC++ .NET 2003. As part of this, I'm fighting through the incompatibilities between mktyplib and the MIDL compiler. If I understood why some of these things were coming out different, I'd have a better shot at fixing them. As it is, I've read the (crappy) Microsoft documentation and find that I'm still in the dark.

On Thursday, Doug gets back from Solutions and -- if this doesn't work -- I get eaten by a grue.