I have an application in which I want to load multiple WPF applications as Modules. Here each modules should come up as a windows but still be able to access multiple modules at any given moment. If I create separate UI threads than some of the modules crash reporting exception that cannot access UI object from different thread than the one who created it. So, is it possible to load multiple modules in a single UI thread?
So, is it possible to load multiple modules in a single UI thread?
Yes, you can load each "module" into the main UI thread. Provided each "module" is defined by a Window, as you suggested, this should work fine - just load them all and show all of their windows.
The one caveat here is that all of the "modules" will be running in one thread, so if one misbehaves (does something that blocks the UI thread) it will block all of the modules.
Related
I'm very new to modules in Prism and am struggling to understand how to use them properly. I want to have a navigation panel like in the image below, which I stole from Google.
Let's say that I have 3 modules for 3 separate concerns: NavigationModule, HelpModule, and FeedbackModule. If I want to show "Help" when the app first loads, my understanding is that I would do something like the following:
Define Regions for navigation and content in my Shell (main WPF project)
Upon execution, load the navigation view into the navigation Region
Upon initialization of the NavigationModule, load a view from HelpModule into the main content Region
This leaves me with a few questions about what modules should know about each other:
Should the Shell's project have a reference to the NavigationModule in order to load its view?
Should the NavigationModule have a reference to the HelpModule in order to load its view? And a reference to FeedbackModule in order to load its views on demand?
If the answer to these questions is "no," then what's the best way for modules to be aware of each other's views? I could create a shared class library with constants for view names, but it seems a bit troublesome to maintain a bunch of strings that way whereas with references I could use nameof(). I would appreciate any direction. Thanks.
Modules should not "know" each other in the sense of having a project reference from one module to another, because that kind of defeats anything gained from having modules in the first place, that is, to have a modular application (built of components that can be swapped out independent of each other).
Modules should interact through shared interfaces, which are define outside of modules, that is either in the framework or in assemblies that "are" no modules themselves. Depending on your requirements, you should define upfront (and enforce in the build process) which modules there are and which interface-assemblies and which module is allowed to reference which interface-assembly.
So how to show the Help-view when the application loads? Send a message (e.g. via IEventAggregator or any other communication mechanism) when it's time to load the initial view (whatever that may be). The Help-module listens for the message and navigates to the Help-view. Important: the SessionResume-module might also listen for our message. It's the responsibility of whomever choses which modules to deploy to only deploy modules that are compatible with each other.
I am putting together a Silverlight 5 application that will run out-of-browser and has a bit of everything on start-up. Specifically, here are the steps I need to follow:
Check that the app is running out of browser (if not, display a screen instructing the user to install it locally).
Display a "splash screen" (it would be nice if this would play animations while the remaining steps execute).
Configure MEF
Pre-load context information and 'static' data from the server (for example, settings). This data is required before any of the application logic can run.
Dynamically load additional XAP files including an external theme library.
Replace the "splash screen" with the shell which contains a navigation frame.
Navigate to the application's start page.
I also need to support Application Extension Services (IApplicationService, IApplicationLifetimeAware) so any process I implement must respect these services. Most of these services will require MEF to be configured, so they should not execute before MEF has been configured and imports satisfied.
Another consideration is that some imports may be satisfied only after the dynamic XAP files have been pulled in and MEF recomposed.
One of the hurdles I'm running into is the fact that I cannot do step 5 until the previous steps are complete. Loading the XAP files or calling the server for data asynchronously allows the code to proceed. I need a way to "stall" the UI until all of the composition is complete and all required context data has been loaded.
So, I'm looking for recommended approaches that satisfy all of these requirements and am happy to provide more details if that helps get to a working solution.
UPDATE
The best explanation I can give for my difficulty is that I must 'release' the UI thread to display a 'splash screen' but also suspend the normal life cycle of the application while each step executes. I can't (and don't want to) do everything in the Application.Start event handler because application services will have already started.
Plus, releasing the UI thread means I do work in the background and let the original method (Application.Start, for instance) return and the runtime will move forward in the startup process. For example, starting a background process in the Starting method of an application service then returning allows the runtime to raise the Start event on the Application object. But if I need the background process to complete before I can do the next thing, I have to suspend the current thread which blocks the UI.
So I'm not sure how to divide up the work or where to put it (App, application service, bootstrapper, workflow, etc.).
You can use ManualResetEvent class to force the service calls to be Sync (and guarantee the order they complete). You could also use this to synchronize the background thread to the main UI thread.
http://mohundro.com/blog/2006/06/27/a-little-bit-about-manualresetevent/
I am having a bit of a problem with a WPF application. The application loads from a database and then creates a bunch of own made Usercontrols. When I load lets say 1000 of these Usercontrols the UI thread blocks. Now I have tried multiple things with loading the Usercontrols on a different thread and then adding them to the main thread, but that is simply not possible I found out (or somebody must have a proper working example).
Is it possible to create a thread with a loading animation that is not blocking while the main UI thread is doing things?
Perform most of work in the thread that loads data from database and use Dispatcher class
http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.aspx
to perform the UI related operations on the main thread.
Hi I am evaluating ICUTest for use on a project. My initial view is that it looks like a promising Visual testing library. The scenario I have for using ICUTest is to start an application with a specific configuration and I expect the main application window to display based on the configuration settings. Each unit test should start the application and then after completing it should shutdown the application gracefully.
At the moment I can get individual tests to run, but when I run multiple tests I start running into all types of threading issues. Has anyone had any experience with this?
There are two ways to test your application.
1) The easiest (and most reusable) way is to just test your main app window like any other window. Do your initialization after a window event (like Window.Loaded) or through the constructor (e.g. new MainWindow("myapp.config") ).
2) If initialization must be done before the window is up then you can start the app thread with code similar to the one here.
Note: in WPF, you can only start an Application once, so method (1) is preferable.
Also, make sure you wrap all your GUI related calls in an ICU.Invoke(...) block.
I have an application designed using Microsoft's Composite Application Library. My shell has several regions defined so that I can inject content from separate modules. I'm looking for a design pattern that will reduce the coupling that these regions introduce.
In all examples I have seen, regions are defined and accessed using a string in a static class in the infrastructure project.:
<ItemsControl cal:RegionManager.RegionName="{x:Static inf:RegionNames.TabRegion}">
public static class RegionNames
{
public const string TabRegion = "TabRegion";
}
This introduces an dependency on the shell from the infrastructure project, because part of the infrastructure project must now match the shell. The CAL RegionManager throws an exception if you attempt to access a region which is not defined, so I must ensure that the infrastructure and shell projects are kept in sync.
Is there a way to isolate the shell's regions so that they are defined only within the shell (no region names in the infrastructure project)?
Is there a way to make regions optional, so that shells can be swapped out even if they don't have all the same regions? (An example: One shell has menu and toolbar regions, another only has the menu... modules should be able to inject into the toolbar if it's available, without failing when it's not)
Update - More details on my architecture
In response to depictureboy's answer below, I wanted to describe the way my system is set up... perhaps there will be more good feedback on it.
I am treating the Infrastructure and Shell projects as generic libraries, and I have several applications which use them. The Infrastructure project provides "framework" code and resources (like MVVM stuff, reflection, icons), and my Shell is a generic host window, with the basic window layout (menus, toolbars, status bar, main content area). The applications all share a common look and behave similarly because they share the shell.
My applications get their individual functionality from the modules which get loaded, so I have a bootstrapper project per application which pulls everything together (infra, shell, modules).
I imagine if I ever need to develop a brand new application that is very different from the current ones, I will be able to re-use the infrastructure project, but not the shell. That is why I am curious about decoupling the infrastructure project and the shell.
I think you have your logic backwards. Your shell is the glue that binds everything together. In my mind you want the infrastructure and shell tightly coupled because they are the application. Your modules are the parts of the application that will be changing and switching around dynamically. You want your shell regions to be static so that, for example, another developer could write a module for your application knowing where his different views were going to be placed and how the application should behave with his module attached. The Infrastructure project is there to be the go between between your shell and its modules...thats just a fact of life at least in my book. One of the WPF gurus may come up with something that absolutely blows that out of the water tomorrow....