Latest Project (or: Why I Hate Microsoft Some Days)

So I decided that I want the user to be able to make standard property sheets (and hence Wizard windows as well) from within REALbasic. This shouldn't be such a scary undertaking, it's just Win32 API magic after all. Well, as it turns out... it's damn near impossible to do from REALbasic.

First, to understand the problem, you have to realize that property sheets are really just a collection of various dialog box resources. If you were programming in VC++ or VB, you'd have the chance to make one of these dialog resources, which the MS resource compiler would then compile down and append to your application's executable during the linking stage. But REALbasic has no way of specifying dialog resources (heck, we haven't even got a resource compiler!), so you basically don't ever get one of these. So you'd think this would be the end of the line, right? Wrong!

Microsoft gives you some APIs to be able to load a dialog via an in-memory template. Usually this template is something you've loaded from the resources section of your executable and have sitting in memory. However, this affords hackers like myself a way to construct a dialog template on the fly so I can create the dialog box. The basic process is this:

You're given a Window and you need to enumerate all the child windows (the controls) to gather information about them. This information includes: position, class type, caption, styles, extended styles, etc. Once you have all that information stored off in a list somewhere, you go back and write out the information about the dialog itself. Once you've gotten that compiled, you write out the information for each child. Seems simple, right? Well, in theory, it isn't too hard. In practice, it's much more difficult. This is because a lot of the information you have is in pixels, but you need to convert them to Dialog Units (DLUs). So once you figure that out, and you go back and correct your code, you realize that you have to padd out a lot of the fields to align on word and dword boundaries. OK, fine. So after correcting that... you can _finally_ get a dialog to display.

You'd think I'd be rejoicing at this point? Well, I am -- of sorts. The problem that I've run into now is that clicking on some controls (not all, things like EditFields seem to work fine, but buttons do not) causes the application to crash. So I did yet another disassembly to see what's going on and I can't make heads or tails of it -- I've managed to jump off into the weeds. So I grabbed a copy of Spy++ to see what the last message is before I crash, figuring this will give me enough insight as to how I am borking things. But alas, when the application crashes, it takes Spy++ with it, which in turns takes the whole OS down.

So where I'm at right now is that I have a mostly properly compiled dialog resource (still have the goofy sizing issues, but I'm not too worried about that) that displays properly with CreateDialogIndirectParam... but as soon as you try to click a button on the new dialog all hell breaks loose and you crash.

Needless to say, now I think I may just end up turning this little project into a full-fledged resource compiler for REALbasic. I always heard that the hardest resource to compile was the dialog (well, that and the version resource), and since I've been able to do that on the fly by inspecting the RB objects... I should be able to just make a small resource compiler. Of course, I think I'd want to do that one via text files, so I'll need to write a quick parser to do it. But still, it'd be an interesting project. Don't get me wrong, I'm still hoping to get property sheets and wizard sheets working with this little experiment. I'm just a little disheartened right now because I've been working on this project since about 11:30am and am just now (7:45pm) getting to the point where I'm running out of ideas on why this is crashing. I'm pretty sure it's related to the way we stuff extra information into the OS object in our framework (since both the original window and the new dialog will end up running thru our event dispatcher at some point). I know it has nothing to do with the dialog compiler itself since the dialog actually displays correctly...

And this is how I spent my Sunday. Man, I wish I had another day off just to get the things done I was hoping to get done today. The weekend just never seems long enough.