My question is, how are you going to use the toolbar in real-world conditions? Let's say you have a word-like application. The toolbar has two groups of buttons, left-center-right-justify alignment, and bold-italic-underline. Where do you want to handle the clicks for these buttons? On the buttons themselves, where you would either have to cache a reference to the document class 7 times (and potentially have to change it when the active document changes) or replicate the code to find it dynamically in 7 different places (granted you could create a DocumentFormatToolbarButton base class and factor that out, but it's still executing multiple times), or have practically every line in your OnClick function start with this.Parent.? IMHO, none of these solutions seem particularly more ugly than a switch statement.
You can make the argument both ways as to what is more useful in the real world. I personally like the fact that they implemented it both ways in the IE WebControl toolbar. (Although you can't set the button click event handler from the designer, only from code.) Anyway, regarding your condemnation of the whole framework not being the 'component oriented platform everyone's been waiting for', you're probably right. But it's the closest I've found so far, and seems likely to continue to get better. - Jim -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Ovidiu Platon Sent: Sunday, May 19, 2002 1:50 PM To: [EMAIL PROTECTED] Subject: [DOTNET] Toolbar problem: Can't teach an old developer new tricks? Hello everybody, So far, I like the current .NET implementation from Microsoft. However, I have noticed some problems that make me think the people at Microsoft haven't really moved to a modern way of doing this programming stuff we're all in. What's my problem, you'll say... Well, the other day I was working with the ToolBar control from the Windows Forms namespace. All cool, create an image list, create buttons and so on... When I double-click a button in the forms designer, I notice that the event handler is named myToolBar_OnClick; I click another button and I get to the same handler. To make the long story short: I wonder why the ToolBarButton class doesn't raise a Click event of its own. The MSDN docs say "create a switch structure and identify the button that was clicked". It looks to me like the people at Microsoft haven't got rid of the WndProc idiom (or I may be totally wrong, who knows?). Unfortunately, this makes me think .NET isn't (yet) the component oriented platform everyone's been waiting for. What do you think about it? Best regards, Ovidiu Platon. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
