How do I route events to a container class instead of main form?
-
I have a TabControl in my application. I have several TabPage's in it and as I add more my main form class is getting more and more cluttered. When you add an event (such as a button click) to a tab page, Visual Studio adds the code to the main form. It seems to me that it would make sense to create a class for each tab page and have the buttons owned by it instead of the main form. Is there a standard way to do this? I've searched the net and haven't found any examples. Thanks much! --- "No one would surrender to the Dread Pirate Westley."
-
I have a TabControl in my application. I have several TabPage's in it and as I add more my main form class is getting more and more cluttered. When you add an event (such as a button click) to a tab page, Visual Studio adds the code to the main form. It seems to me that it would make sense to create a class for each tab page and have the buttons owned by it instead of the main form. Is there a standard way to do this? I've searched the net and haven't found any examples. Thanks much! --- "No one would surrender to the Dread Pirate Westley."
If you have more than a 100 or so controls on a page you probably have too many as a general design principle. As for tabs, one common method is for each tab page to contain a control. The control would have the UI portion on it. Then through public properties and events listeners could be used.
File Not Found
-
I have a TabControl in my application. I have several TabPage's in it and as I add more my main form class is getting more and more cluttered. When you add an event (such as a button click) to a tab page, Visual Studio adds the code to the main form. It seems to me that it would make sense to create a class for each tab page and have the buttons owned by it instead of the main form. Is there a standard way to do this? I've searched the net and haven't found any examples. Thanks much! --- "No one would surrender to the Dread Pirate Westley."
imho, your suggestion is very logical, but implementing it (in my experience) and other associated functionality is far beyond the practical limits of project development. It's a library development issue, and certainly not a lightweight one. I'm working on both C# and C++ library implementations which will accommodate you, but not for a few months down the road. Nonetheless, in the current IDE implementation, indeed the pages are separate classes. The reason they are owned by the form is so that they may be supported by the form's designer. This is essential to the current serialization scheme. Your "standard way" of doing this requires revising this whole system for some ostensible class design advantage. But your real complaint (if I understand you correctly) is the cluttered implementation of your conventional page control. Indeed, it has critical limitations, not just because it wastes space, or even because it may not internally manage resources as efficiently as a scheme might... but because your project may require so many pages that the navigation system (the tabs) would require all the available interface real estate. OK. Some people will immediately scoff, "That would be a crazy application design." But no, with a good design and underlying architecture provided by the underlying control, you can do this very efficiently and build applications which (through further shared resources) get much more accomplished than MDI implementations for instance can on the same footprint. One thing I can suggest for you to save some interface real estate is to nest page controls. Build an outer page control which branches to several categories of interfaces, and navigate through branches to destinations. This of course imposes extra clicks on navigation of your application. Solve the extra click issue by building shortcuts from within your pages to destination pages -- focusing the necessary outer page controls to do so. Wherever possible, also focus intended data. In other words, if you have a Property record which references an owner field, don't just provide a shortcut that focuses the owner page, leaving the lookup to the operator. Make your shortcut focus the necessary Owner record as well. This will make your users happy for the while. Better solutions yet are just down the road.
-
imho, your suggestion is very logical, but implementing it (in my experience) and other associated functionality is far beyond the practical limits of project development. It's a library development issue, and certainly not a lightweight one. I'm working on both C# and C++ library implementations which will accommodate you, but not for a few months down the road. Nonetheless, in the current IDE implementation, indeed the pages are separate classes. The reason they are owned by the form is so that they may be supported by the form's designer. This is essential to the current serialization scheme. Your "standard way" of doing this requires revising this whole system for some ostensible class design advantage. But your real complaint (if I understand you correctly) is the cluttered implementation of your conventional page control. Indeed, it has critical limitations, not just because it wastes space, or even because it may not internally manage resources as efficiently as a scheme might... but because your project may require so many pages that the navigation system (the tabs) would require all the available interface real estate. OK. Some people will immediately scoff, "That would be a crazy application design." But no, with a good design and underlying architecture provided by the underlying control, you can do this very efficiently and build applications which (through further shared resources) get much more accomplished than MDI implementations for instance can on the same footprint. One thing I can suggest for you to save some interface real estate is to nest page controls. Build an outer page control which branches to several categories of interfaces, and navigate through branches to destinations. This of course imposes extra clicks on navigation of your application. Solve the extra click issue by building shortcuts from within your pages to destination pages -- focusing the necessary outer page controls to do so. Wherever possible, also focus intended data. In other words, if you have a Property record which references an owner field, don't just provide a shortcut that focuses the owner page, leaving the lookup to the operator. Make your shortcut focus the necessary Owner record as well. This will make your users happy for the while. Better solutions yet are just down the road.
Thank you both for your quick replies. It does seem like Visual Studio doesn't have an easy way to create a class to hold all the controls in a tab page. I'm not sure if this was the meaning of having each "tab page containing a control" but I took that idea and added a UserControl which created a container for my buttons and such. When I added it to the tab page it displays the design at least (although I couldn't edit it directly) and it does route the events to the UserControl UI correctly. Is this how you suggest I do it? Or is there something simpler? Thanks again.
--- "No one would surrender to the Dread Pirate Westley."
-
Thank you both for your quick replies. It does seem like Visual Studio doesn't have an easy way to create a class to hold all the controls in a tab page. I'm not sure if this was the meaning of having each "tab page containing a control" but I took that idea and added a UserControl which created a container for my buttons and such. When I added it to the tab page it displays the design at least (although I couldn't edit it directly) and it does route the events to the UserControl UI correctly. Is this how you suggest I do it? Or is there something simpler? Thanks again.
--- "No one would surrender to the Dread Pirate Westley."
The reason you cannot (yet) edit it directly (evidently) is you probably haven't authored properties which interface the composite control you have built. It's commendable you have gotten that far, actually. That's pretty good. What I had in mind as sharing controls for all your pages -- in other words, use one set of controls built into your page control, and focus those on material of the focused/active page. That's just an alternate suggestion, and it is only pertinent if it would suit your purposes. But it is the most efficient way to go, because instead of deploying many controls, each of which do a given thing with given objects of one page, each of those controls is focused on the objects of the whatever number of pages... one page at a time of course, with the one page being the focused page.