1) Yes because the conductor when combined with Collection inherits a collection property Items, it will also know ActiveItem. Take a look at HelloScreens its a Silverlight variation but it shows screen composition. But also understand you can have more than 1 conductor to varying degrees controlling different parts of your applications structure. I think what is going is your application has one part that is being conducted and another that is not and therefore parts are not being activated.
2) Master / Detail pretty common design. Selecting a Caller will tell the system to get the "details" of that caller and present them on a tabitem (which is a usercontrol in context), cm does all the heavy lifting in this case.
3) Design choice they could has been derived from Screen its all a design choice. what I generally do is a ViewModelBase (which is of type Screen, I don't export based off of Screen but actual name of the ViewModel cause I call it directly not via Conductor mechanism) which has other stuff in it for myself but I am not using the Conductor in my application since I wasn't looking for dynamic construction of my application but instead on demand need. If it makes senses to you in the end then it works.
4) When you are exporting you effectively saying here I am do what you want, MEF is just looking for parts to distribute around application as you tell it. Don't forget though MEF also looks at signature of the request and if it doesn't match what is required by the request exactly it will just twitch and die...
5) Inherit from Screen, export off of IScreen is perfectly ok, since Screen inherits IScreen anyway.
Snoop might help, might not...
2) Master / Detail pretty common design. Selecting a Caller will tell the system to get the "details" of that caller and present them on a tabitem (which is a usercontrol in context), cm does all the heavy lifting in this case.
3) Design choice they could has been derived from Screen its all a design choice. what I generally do is a ViewModelBase (which is of type Screen, I don't export based off of Screen but actual name of the ViewModel cause I call it directly not via Conductor mechanism) which has other stuff in it for myself but I am not using the Conductor in my application since I wasn't looking for dynamic construction of my application but instead on demand need. If it makes senses to you in the end then it works.
4) When you are exporting you effectively saying here I am do what you want, MEF is just looking for parts to distribute around application as you tell it. Don't forget though MEF also looks at signature of the request and if it doesn't match what is required by the request exactly it will just twitch and die...
5) Inherit from Screen, export off of IScreen is perfectly ok, since Screen inherits IScreen anyway.
Snoop might help, might not...
