New Release: SRP ActiveX Controls

SRP ActiveX Controls 4.2.2 is now available. You can view all the changes here.

You will notice that the size of this update is not very big. The last update was in May of this year. Six months later, you can’t be blamed for expecting a cornucopia of new features and improvements. What gives, Kevin? Have you lost your mojo?

Let me tell you a little story.

Not long after the last update, I found myself discontented with the layout of OI controls on forms that utilize the SRP Ribbon Control. The goal with any SRP Control is to make it as drop-in ready as possible. To that end, the Ribbon Control attempts to make room for itself at the top of the form and adjust all the controls accordingly.

This was never working as well as I wanted it to in OI 9. The Ribbon would end up fighting against OI’s auto-sizing algorithms thus causing controls to be off by slight amounts. To my pleasant surprise, this was nearly a non-issue in OI 10.

It’s no secret that OI uses the Win32 API to generate forms and controls. OI 9 simply places all controls directly in the client space (the non-border, non-title bar space) of the form. The form then takes care of control placement and auto-sizing. OI 10 cleverly places all its controls on an intermediate control called the Client Frame. The client frame takes care of repositioning controls, so the form only has to worry about filling up its client space with the Client Frame. It’s a great design that allows OI 10 a lot more leeway over how controls are placed.

As you might imagine, this is a breath of fresh air for the SRP Ribbon Control in OI 10. All I need to do is move the Client Frame down a bit to make room for the Ribbon Control and, voila, everything adjusts like magic (with one exception we’ll discuss below).

This got me thinking… and thinking got me into trouble.

Why not just do this in OI 9? With the power of all my mojo, I updated the SRP Ribbon Control to create a client frame of my own, a clever little copy of an OI form done without the presentation server’s knowledge or permission. It wasn’t hard. Just use the window class name (“RTI_PrCl”), call CreateWindowEx, move all the OI controls from the main form to the new one, and bam, I’m cooking with fire!

This worked perfectly. The controls adjusted with pixel perfect accuracy, and it simplified my codebase.

Then came the forum posts. Modal dialog boxes were leaving the form disabled. Message boxes were not returning values. Edit lines stopped responding to mouse messages. This didn’t happen all at once, mind you. They came sporadically, and in each case, I spent an embarrassing amount of time trying to work around the issue. I thought I could stay ahead of the side effects and beat the presentation server at its own game. I trusted too much in my mojo.

Eventually, I had to throw in the towel.

OI 9 doesn’t use the PARENT property of a control to find its parent. Instead, it walks the control hierarchy utilizing different assumptions each time. Sometimes the next control up is the parent, and other times the topmost non-child form is the parent. The hard truth I had to accept was that my secret client frame control was Mayhem in OI 9, and the work arounds kept getting increasingly silly with me going so far as altering x86 op codes to intercept low-level Win32 API calls. Eventually, my hackery could no longer suffice.

It was time to cut my losses and embrace a more stable solution, one that was available to me from the start were it not for my hubris: have the programmer tell me where the controls go. And that’s what this version does.

There are two new features for the SRP Ribbon Control: the LayoutChildControl method and the MDISize property. The former is for OI 9, and the latter is for OI 10.

If you use the SRP Ribbon Control in OI 9 and want pixel perfect accurate placement of controls, use the LayoutChildControl method instead of using the SIZE property. Pay attention, though, because this method does not use the same structure as the SIZE property. Instead of setting X, Y, Width, and Height, you set Left, Top, Right, and Bottom. Any of these values can be negative to mimic auto-sizing.

If you use the SRP Ribbon Control in OI 10, then you should use the MDISize property to reposition the MDICLIENT control instead of the MDICLIENT’s SIZE property. Remember when I said OI 10 puts all controls on the client frame and makes life a breeze… well… the MDICLIENT is the only exception. Instead of being a child of the client frame like the rest of the controls, the MDICLIENT is a sibling to the client frame, so it doesn’t nicely resize like the other controls. By using the MDISIze property as a drop-in replacement to the MDICLIENT SIZE property, everything should look nice and tidy.

That is my story. I learned some important things about presentation servers, parental hierarchies, Win32 API hooking, and most importantly, mojo. Mojo is not winning all the time, as though winning should be easy. It’s finding the right path amidst failures with an attitude that says, “Yeah, baby.”