> Yes, especially seeing as MS have selfishly sealed anything > remotely useful from sub-classing of the MessageBox class.
Sealing has nothing to do with it. The limitation is intrinsic to what it does, and sealing contributes nothing to that problem. In fact, it's not actually sealed in .NET v2.0. The superficial reason you can't derive from it is the same reason you can't instantiate it: its constructor is private. But that's not the underlying reason - even if they changed this and let you instantiate and derive from the class, the limitation would remain. Sealing is irrelevant here. First of all, MessageBox.Show is static. In fact all the members of MessageBox are static. You never actually instantiate the MessageBox class. Even if you could derive from it, there's nothing useful to inherit. Logically speaking, MessageBox is a namespace containing a bunch of global functions. Except of course C# doesn't support global functions, so they have to be wrapped up as static methods in a class. If the CLS required .NET languages to support global functions, MessageBox probably wouldn't be a class - logically speaking its members all behave exactly like global functions. So even if you could derive from MessageBox it wouldn't serve a useful purpose. (No more than it would be meaningful to deriving from a namespace.) The limitation is, as you say, that the class isn't very .NET. (And that's because it's a straightforward wrapper around simple procedural Win32 API.) The fact that you can't derive from MessageBox isn't the cause of the problem. If they did let you derive from it, you'd simply be able to waste some time discovering you can't extend it. (At which point, you could reasonably say "They should have sealed this!") (Sorry for the rant - it's just that there's a persistent meme that's been doing the rounds for the last few years: this idea that sealing is the cause of limitations rather than the expression of intrinsic limitations... So when sealing is incorrectly identified as the cause of a problem, I feel the need to point out that it's not! :) ) -- Ian Griffiths -----Original Message----- From: Kelly, Brady > MessageBox() (the historical ancestor of the WinForms version) > was historically a pretty black-box thing; if you need that level > of control you probably want to write your own similar routine. > > Ted Neward Yes, especially seeing as MS have selfishly sealed anything remotely useful from sub-classing of the MessageBox class. Probably because there is nothing to inherit from the very Not.NET class. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
