Hi, Pertti.
>Tribal Knowledge in my book is something that is not self evident, something that a programmer loses hair over without additional help, something that you have to turn to the Tribe to get answers for. Is the "perfectly acceptable and correct way of doing this" explained clearly in .NET documentation? If not, it is Tribal Knowledge. If yes, how did this become an issue to begin with?
>
>And furthermore...
>
>The bottom line to me is: Why would visual heritage have to be something "discoverable" and not something "consistent"? As far as I'm concerned, if you change a property, ANY property, in a parent class, the change should be immediately and without any further action on behalf of the programmer be reflected in the child class and classes below it, unless it is specifically overwritten somewhere down the ineritance chain. So,
if you change font or any other properties, methods or events in one class, all classes that inherit from it must get the message without further ado. If this is not the case, you grossly break inheritance, and now you have to keep in mind all of the exceptions to the rule (kind of like learning German...). The .NET font shenanigans(*), quite frankly, s*ck. You either inherit everything or you inherit nothing. Anything more or anything less, to me, is unacceptable.
Inheritance in .NET is the same as in most other platform. The only thing getting in the middle here, and something you pretty early discover and have to understand, is how the designers work, as they generate code to support many things. I don't like the WinForm approach very much, but it is something you quickly overcome.
This is not a showstopper or a deep little secret at all. There are plenty of examples in the MSDN docs and everywhere else about Visual Inheritance and the like. I remember in the early days of VFP having to explain to many folks how VFP inheritance worked and why you could get weird results because some annoyance in how VFP 3 handled the overwritten properties. This is much the same.
As usual, the main issue is judging .NET from a very VFP-centric perspective. There are many things that sound silly or wrong for a VFP developer, until you get used to them, understand the logic, and sometimes you realize it is more flexible, much better, or actually silly... 8-) Every platform has its quirks, and a huge one like .NET have many, but it is nothing compared to its strengths.
Just for the record, if you need to build smart-client (non-browser based apps) in .NET at some point, I'd jump right to WPF instead of WinForms. This is an absolutely better model imho, and one you would surely love.
Regards,
