But the more you talk about this, it seems to me you have a view model, not a controller. Maybe I am missing something. anyway I find that MVVM fixes all those binding issues.
You could be right. I might have only partly (or incorrectly) implemented MVVM due to bias from years of using VM. My controllers might be living in the wrong place and have the wrong lifetime. This is the structure I have: I have a set of "service classes" that manage logging, config, settings, messaging, emailing, etc that are prepared when the app starts. They live as long as the app and are accessible anywhere thanks to a singleton "service locator" that holds them all. (CAB does this) Each View (UserControl) has a corresponding controller class that is defined in the view Resources (as in my sample code yesterday). The controllers all have references to the services and other common stuff. The controllers all talk to each other via simple message broadcasts. Views bind properties and events to the controller. Because I'm having trouble with the "lifetime" of the view and its controller, I suspect I have a design problem with the way the controller is a resource of the view. What is the recommended MMVM way of doing this? Where do the controllers live and when are they constructed? When are they bound to their view? Can someone point me to a minimal MVVM sample that shows the recommended way of structuring the MVVM pieces? I'll keep looking for one in the meantime. Cheers, Greg
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
