Don't get too alarmed, but I'm writing for two blogs now. I just contributed my next tutorial to REAL Software's official blog rather than my own:

REALbasic's New TrueWindow Feature

As much as I love writing content on my own blog - and I'll continue to do so - it makes more sense for the company if I do the tutorials and such in a more official capacity.

The new post walks you though some usage scenarios for the TrueWindow property. I find it very useful, and it was one of my posts that this feature was based on. Norman implemented it though.

The question has come up though, why TrueWindow, why not just "fix" the Window property? If you've read Aaron Ballman's blog in the past, I bet you'll figure out the answer. It's because changing the behavior of Window would break code in a non-obvious way. A good chunk of code would continue to work as expected. But some code, especially code that walks up the hierarchy to find a RectControl's global screen bounds, would go haywire. It would not trigger compile errors, stuff would just start going wrong. We can't have that.

We could have renamed the Window property to trigger compile errors, but that would cause alarm when developers would open the project in the new IDE and try to build and be presented with lots of "This method does not exist" errors and cause a big WTF moment. We don't like that.

This way is most code-compatible... as long as you don't have my other TrueWindow methods in your project of course.