New Post: How to create a separate XAP file using Prism/MEFBootstrapper for a complex Child Window?

gan_s wrote:

To make myself clear I never suggested adding a reference to the childwindow module (your SharedFormsModule). I suggested keeping it loose by exporting a typeof(ChildWindow) as ChildWindow is part of the sl framework itself. You can do it using interfaces, but that needs to be shared between your module and the shell, which you dont have to worry about in case of ChildWindow. I have done this in my app and it works absolutely fine.

As above you will just need to add the AllowDefault=true and AllowRecomposition=true for it to get repopulated once your module gets downloaded. To check you could even implement theIPartImportsSatisfied in your shell to check if the OnImportsSatisfiedgets called once your module is downloaded and check if your childwindow properties are populated.

 

[Import("SMMMessageWindow", AllowDefault=true, AllowRecomposition=true)]public ChildWindow SMMMessageWindow { get; set; }

[Import("ErrorWindow", AllowDefault=true, AllowRecomposition=true)]public ChildWindow ErrorWindow { get; set; }

 

I would still not go the interface way as that's an additional abstraction and it really isn't doing much in your case other than just callingShow() on your childwindow. Too much of abstraction is not needed in your case. 

Hello gan_s,

Thanks for your help. I did not mean to imply that you said to use a reference to the child window. The confusion has been on my end. I see the merits in both approaches that have been suggested and can see applications of both in my current project. That is why I working both approaches to completion.

One thing that had confused me was that you had recommended using the following in an earlier email.

[Import("SMMMessageWindow")]
public ChildWindow SMMMessageWindow { get; set; }

As you pointed out in your last email, by setting the AllowDefault and AllowRecomposition true the exception that I was experiencing went away. This make a lot of sense now. The application does not know anything about the import until after the module is loaded. Once loaded, the recompositon can occur and the import resolved.

I did the following to get your approach to work.

1. Set AllowDefault = true, must be set true for OnDemand loading to allow a value of null or its default value when the property is first imported.
2. Set AllowRecomposition = true, must be set true to accommodate the change in the property after the module is loaded.
3. I had to set evt.Error == null, rather than if (ErrorWindow != null && evt.Error != null) as you mentioned in your email.

I now have both approaches working thanks to you, Agustin, and Damian. Sorry it took me so long to absorb the basics.

There may still be a problem with the approach based upon some of my other requirements, at least for some code modules.

1. First, from my research, it appears that these techniques rely on a parameterless constructor. From what I have read, there is no provision for importing a class with multiple constructors using MEF or passing parameter to the imported class. Are these assumptions correct?
2. Second, I assume that these two approaches cannot handle a static class since it cannot derive from an interface and may not be derived from a public class (like ChildWindow). Is this assumption correct?
3. Third, I assume that an interface is required if you want to actually use any public properties or methods? Is this assumption correct?
4. Lastly, is there any supporting MS technologies that allow multiple constructors and parameters to be passed through Prism modules.

Thanks again for all the help...

Warren