Monday, February 25, 2008

Interop, Interop, and more Interop

Well, we're sure doing our fair share of WinForms and WPF interop! We've really jumped on the WPF bandwagon, but we really like the functionality of our application and aren't willing to give up major parts of it in order to go 'all' WPF.

For instance, our Syntax Editor control (from is only available currently as a WinForms control. Also, my management really likes the Infragistics Grid's functionality that we're using for our selection grid in our formula browser tab. In addition, we really like our tabbed MDI style of windowing, and our tool windows (pinnable tool windows like in VS2005).

Unfortunately, there are several ways in which WinForms doesn't play nice with WPF. Basically, the problem is that when WinForms draws on a window, it 'owns' that space on the screen. However, when WPF draws on a window, it is using DirectX compositing. This makes lots of things in WPF very nice, but in order to allow WinForms controls to 'live' on a WPF window, they must have total control over the space where they 'live'. This means that the WPF controls can not render 'on top of' the WinForms control. This is very well documented behavior and basically the only way the WPF team could figure out to make this work (as far as I can tell).

What does it mean for us? A whole lot of interop. Basically, we want to use WPF everywhere we can and would love to be able to use it for our whole application. Currently, we can't use it for the whole app, and so we must use it where we can and hope for the best later. However, tool windows have this neat 'auto-hide' feature with them. We really liked the WPF 'SandDock' tab & dock controls from DivElements. However, since our WinForms grid is in the main client area of our form layout, we couldn't use a WPF docking control, since when you drug the dockable windows around, or when they tried to 'flyout' from their 'auto-hide' position, they would do so UNDER the WinForms control! That sucks, but it's the only way it can reasonably work.

What's that mean? Our docking controls can only be WinForms controls until we get rid of all the WinForms controls that a flyout would want to fly over (and replace them with WPF equivalents). Now, since our docking and tabs controls (they're the same control for us, since we've switched to Actipro's UIStudio) have to be hosted in WinForms, and you can't have a WinForms host inside a WPF host inside a WinForms host (the interop facilities of WPF only allow WF inside WPF or WPF inside WF, but not 'double' nesting), we MUST use WinForms for our main application (this sucks since it means we lose a bunch of the nice features of WPF, like commands, command bindings, routed events, etc.).

This also means that EVERY WPF control in our app must be hosted inside a WPF element host (interop) control on the WinForms form.

Yuck. That's a hell of a lot of interop.

Wednesday, February 20, 2008

Portrait Mode

So, have you guys heard of "Portrait mode" for monitors? If not, you should really check these out - here's an example of what it is:

It turns out that portrait mode is actually a feature of your video card, not your monitor. What makes it a "feature" of the monitor is simply that a monitor that supports portrait mode must have a stand that allows you to rotate the monitor.

So... it turns out that the Dell 20" Widescreen LCD panel that I've had on my desk in the Milliman office for 6 months now is actually a 'portrait-capable' monitor. Of course I had to hire a new employee in order to figure that out :)

Of course, after setting up my monitor at the office to do portrait mode, I decided I needed to check to see if my Samsung SyncMaster 225BW supported it (my home monitor). After doing a web search, it seemed that it didn't, so I did some investigating of my own. This monitor is absolutely awesome, and this is the very first design 'flaw' I've seen with it so far. However, it turns to be a weirdly long-sighted and simultaneously short-sighted design!

The stand on the 225BW is removable, and has a square mount. Inside the back of the monitor, the metal substructure has four mounting studs. Woohoo! I say, it seems like I can rotate this thing after all. Unfortunately, there are two mounting ears on the stand that fit into some holes in the plastic case in order to ensure that the monitor doesn't pull away from the stand when tilting it (it only mounts with two screws - the top ones).

So, long story short, I pulled out some cutting tools and cut myself a couple of holes in the plastic case (it's backed by the metal substructure, which I verified before cutting so that I wouldn't damage any components). Voila! - I now have a portrait mode monitor! I can fit 351 code lines in visual studio on one screen given my current toolbar settings (and the error list/bottom windows unpinned) - WAY COOL! I can taste the productivity already!

Monday, February 11, 2008

Collections library for .NET

Here's a neat collections library somebody just mentioned in one of the newsgroups I frequent. I haven't had a chance to check it out much yet, but it seems very promising.

Saturday, February 9, 2008

Interesting Blog Post - SKU driven development

Jeff has a very good post here. Mostly, I like the bulleted list in the post, I think it's one of the best lists of 'must read topics' I've ever seen in one place.

Friday, February 8, 2008

BNF in code?

Ok... this is pretty cool.

I was very surprised this works. I wonder how expressive you can really be with this, but it's an interesting idea.

Wednesday, February 6, 2008

NETfx source code...

Get it while it lasts!

Chris blogs about a tool that will let you get the whole distro in one fell swoop!