And the bug came back.
We went through a couple of cycles like this before I managed to find out that the problem was with our old client application, not the new one, although the bug had been tagged for the new client. Ok, that happens. And I still couldn't get the old client to fail.
So I asked if I could log into the test system so I could see this for myself. And I was given a login and password.
That didn't work.
Two more cycles like that and I finally got a login and password that would work.
I pulled up the app, opened a file, opened the Save As dialog, switched the file type, expecting that nothing was going to happen.
And the app crashed out from under me.
What the heck?
So what. I'm going to believe my own lying eyes?
So I crashed it again.
Mutter, mutter, curse.
I pulled up the source code for our dialog, which is derived from MFC's CFileDialog class. And I found that someone had put in a handler that would get called when the file type was changed and we were doing Save As. The handler called a function that would use a resource ID in the dialog to allow us to update the file name and append the new extension.
Well, it used to call that function. But someone had complained about it "not working" and had copied up the MFC code for the function because there was "a bad prototype". And that code crashed every time.
Now we had recently updated from Visual Studio 2005 to Visual Studio 2010 and gotten a new version of MFC in the bargain. Time to go read the source code again.
Oh, look! If you are on Windows Vista or better, the CFileDialog will default to using the nifty new Common Item Dialog instead of the ugly old Common File Dialog. Our tester was on Windows 7. I run on Windows Server 2003. Oh. And the old resource ID for the old version of the dialog isn't present in the new version of the dialog, but there are nifty functions that you can call to do what we need to do.
Except our app is still targeted to run all the way back to Windows XP, so when we compile our dialog, we can't see the interface for the nifty new functions. Mutter, mutter, curse.
I could force everyone to use the old pre-Vista dialog no matter what OS they were running on, but by now I was pretty annoyed and determined to make this work. And because I had pushed our derived file dialog out into a DLL, I could make this happen.
So I told the DLL compile that it was ok to use Vista features. Then I checked to see whether we were using the new or the old version of the common dialog class in the handler. And if we were using the new version, I updated the info using the nifty new Vista version. If we were using the old version, I plugged in the old MFC function that set the value of the file name using the resource ID and the function that updated the information that way.
And I managed to get this to compile on my Windows 7 laptop (which was another adventure, because my Remote ClearCase install remains bollixed up) and test it there successfully. And I compiled it on my Windows Server 2003 desktop and tested it there successfully.
I have now checked in the changes and have closed this bug.