"Ronald S. Cook" <rc***@westinis .comwrote in message
news:4B******** *************** ***********@mic rosoft.com...
Thanks David.
So for a basic Windows app, would you climb the learning curve of CAB and
introduce the associated complexities?
Add-on frameworks, no matter how good they are, a significant investment.
If you need an MVC-type UI framework, use CAB. If you need a modular,
composable UI, especially one where different teams are delivering modules
that need to interact, use CAB. These are the hard problems that CAB
solves. Basically you need to decide that you have an important requirement
that CAB can help you deliver to justify learning it, implementing it and
forcing it on anyone who comes after you to learn.
>
How else would you suggest structuring the UI of a Windows app where you
can still keep "shell" functionality on some sort of a master form, by
using user controls for all module-level functionality?
If you need that kind of modularity, you should invest in learning an
implementing CAB. Otherwise you risk ending up with something both complex
and poorly implemented.
If you roll your own, you will eventually need to be able to:
1) Control loading and initialization of your modules
2) Enable access by modules to shared services
3) Enable access by modules to shell-level UI features (menu bar, status,
tree views, etc)
4) Enable eventing to and from loaded modules
5) Manage the dependencies between modules and between modules and shared
componenets
6) Provide guidance to other developers for delivering modules
All of which CAB addresses.
David
