Well, in the first place, I want to say that I'm not condemning the whole .NET platform nor the MS designers. So far, it's the only platform that I've felt *really* comfortable programming with (I'm not as experienced as some of the guys around here since I learned programming only about 6 years ago, but I've worked with quite a lot of things so far, from Turbo C to Java 2). As about your example, I have to say that you got it wrong: I wished for a button class that could *raise* events, not a class that could *handle* events. This way, I wouldn't have to hold Parent references, as you suggest, but the toolbar would hold the buttons and the view, the doc (assuming I'm using a MFC-like doc-view model) or the main app would connect handlers to the buttons' events. For complex cases, such as the radio group you mention, I (or a framework developer, for that matter) could implement a ToolBarRadioGroup class that would handle this scenario and would raise specific events of its own. Actually your example applies to the app I'm working on right now: I have a group of 7 ;-) buttons; at one time only one can be selected in order to insert some thingies on a form. Hoping for a better world (and for cool class libraries), Ovidiu Platon.
-----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Stanton Sent: Monday, May 20, 2002 5:05 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Toolbar problem: Can't teach an old developer new tricks? 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
