I've been creating a WPF application that initially loads as a task bar icon and then when clicked opens an appropriate window. This was a prototype and I want to move over to Prism and having watched the (superb) videos by Mike Taulty (channel9.msdn.com/niners/mtaulty) I have the feeling that what I need to do is create an application with a custom bootstrapper that does all the service registration but does not create an initial shell but instead simply loads the modules and perhaps identifies a module to Run. Has anyone anyone done something similar, if so how much work am I in for?
OK I bit the bullet and just tried it. I should first state that I was using the Autofac version of the Bootstrapper.
I returned null to CreateShell
I marked the apps ShutdownMode="OnExplicitShutdown" in the declaration at the top of App.Xaml (important otherwise it closes the application when you close the last window)
I created a module (IModule derived) that loaded the WPF notify icon by Philipp Summi (http://www.codeproject.com/Articles/36468/WPF-NotifyIcon)
In response to a command from the context menu on this icon I simply create the window and it's view model and show it.
This all works just as I had hoped. The only thing I have yet to do is see how to use regions with these temporary windows although other articles appear to have this covered. I'm not convinced the Autofac bootstrapper gives me any great advantages but I had developed a very early prototype using Autofac and stuck with it because it went smoothly. I will probably go with Unity or MEF in the long run just to avoid compatibility problems and to allow dynamic module loading from external plugins.
Related
I am wanting to rewrite one of my Revit Add ins so that it utilizes WPF with MVVM because I like the look and functionality of WPF better than Windows Forms.
I have used the Revit Template Wizzard from Jeremy Tammik for the Form based add in, but adding a WPF user control seems not to work (a run time error that the xaml resource cannot be found).
I found a WPF MVVM revit add in example (AddMaterials, here is the github link, which will add materials from an Excel spreadsheet) but it does not follow what I am expecting to see at the top level.
Revit Add ins have an app.cs file which tells Revit how to register and access the DLL (ribbon panel buttons etc).
A windows WPF app will have app.xaml as the top level entry point.
The Add Materials project has neither which tells me that it must be
a class library, however the views are not using UserControls
rather they are Windows which I prefer. However Visual Studio does not
let you add a Window for a Class Library type project.
The third issue is easily solved by simply copying windows from a WPF application project into a class library project. But I don't really understand how the class library will instantiate in Revit without following the app.cs code from the template. Is anyone else creating add-ins this way, and if so can you let me in on any tricks or discussions that will help? Has anyone created a WPF Revit addin template for Visual Studio?
When I add a WPF window and try to instantiate it I get an error that it cannot find the xaml resource (System.IO.IOException: Cannot locate resource 'xxxx.xaml'). I have tried to fix this according to advice found when googling for this error, but to no avail. I am thinking it comes from being in a form based project, and that I may have to just start with a new project without the form stuff.
I have now verified that indeed you can start with the Revit AddIn Wizzard and use WPF . . . I started from scratch and copied in a window created in another project and got it to run (after adding the various references, namespaces, etc). So my problem seems to just be with the original project which already had a bunch of form stuff added.
Yes, I'm using WPF to create Revit Addins. It works well. You can easily create your own WPF template from the SDK samples:
Start with one of the Autodesk-provided SDK samples. I used the "DockableDialogs" sample. I know this one works, your mileage may vary with the others. If you're looking for windows rather than docked panes in the UI, another sample (perhaps the AddMaterials sample) is probably simpler.
I used Visual Studio to turn the sample into a template. File - Export Template -> select "DockableDialogs" or other WPF sample project.
Create a new project based on the template you just created. This was the easiest method I could find to get the WPF internal bits wired up correctly.
I'm not specifically familiar with the AddMaterials project, but to clarify your bullet points.
Revit Addins - It's not the file name (app.cs) but rather they must extend IExternalApplication or IExternalCommand. If you are creating a xaml interface (rather than just running a command from a ribbon button) you'll use 'IExternalApplication' as your entry point. Look for something like this in the sample:
public class ThisApplication : IExternalApplication ...
I don't used a top level app.xaml, but instead have page.xaml pages which are called by the Revit app. In my case these are Pages rather than Windows, which extend the IDockablePaneProvider class. These must be registered with the application which can then can be show, hide, etc your Panes. I imagine this is simpler with Windows, but haven't done it myself. For the dockable panes, your xaml.cs should start out something like:
public partial class MainPage : Page, Autodesk.Revit.UI.IDockablePaneProvider ...
Yes, the project is a class library in the sense that it is a collection of classes, at least one of which extends IExternalApplication or IExternalCommand. Remember that you're not creating a standalone application, but adding functionality to an existing Windows application (Revit). Revit will instantiate the ThisApplication class and then call its .OnStartup() method when the Revit application starts. This shouldn't stop you from adding .xaml or .cs files to the project, though. I can do it using VS Community 2015 using Ctrl-Shift-A.
Hopefully this gets you started - I've been able to implement a WPF UI in Revit without any prior WPF experience, and I'm not even a real programmer, so it's definitely possible. Good Luck!
addendum
If you want to add WPF elements to an existing revit addin, you can follow the instructions here: How can I connect xaml and xaml.cs files
Ultimately I found it easier to migrate my addin code into a template made from a working sample, you may want to try this approach as well.
I've done .Net development for awhile but I'm new to the WPF technology. What is the supposed purpose of App.xaml? Also, what type of xaml code do you usually put in it? It seems like for simple applications it could be ignored and left untouched. Is this true?
App.xaml is the declarative portion of your code (usually generated by Visual Studio) extending System.Windows.Application. For example, Expression Blend can use App.xaml to share a Resource Dictionary or a design-time data set with your entire application. And, because we are using Microsoft products, whatever Expression Blend can do auto-magically, we can do by hand in Visual Studio.
Now the tangent: To me, to ask about the purpose of App.xaml is to ask about the purpose for System.Windows.Application. Feel free to accuse me of changing the original question (let the digital brutality ensue).
You can’t just open a System.Windows.Controls.Window in any Assembly you like… Chris Sells is likely telling me this in his book. I began to understand the purpose of System.Windows.Application while using MEF and MVVM Light to display WPF windows in DLLs (not EXEs). I got errors like this:
The type 'System.Windows.Markup.IComponentConnector' is defined in an assembly that is not referenced.
or
The type 'System.Windows.Markup.IQueryAmbient' is defined in an assembly that is not referenced.
The above error is simply saying that I’m trying to open a WPF Window inside of a DLL and not an EXE. Then, there’s this error:
The component 'Songhay.Wpf.WordWalkingStick.Views.ClientView' does not have a resource identified by the URI '/Songhay.Wpf.WordWalkingStick;component/views/clientview.xaml'.
This boils down to the absence of a facility that associates WPF Window XAML with the WPF “code” (an instance). This facility is associated with WPF EXEs and not WPF DLLs. Visual Studio auto-generates a WPF EXE class called App.g.cs (in your \obj\Debug folder) with this call in it: System.Windows.Application.LoadComponent(this, resourceLocater) where resourceLocater is a badly named variable containing a System.Uri pointing to the XAML like ClientView.xaml mentioned above.
I’m sure Chris Sells has a whole chapter written on how WPF depends on System.Windows.Application for its very life. It is my loss (quite literally of time) for not having read about it.
I have shown myself a little something with this unit test:
[STAThread]
[TestMethod]
public void ShouldOpenWindow()
{
Application app = new Application();
app.Run(new Window());
}
Failing to wrap a new Window in the System.Windows.Application.Run() method will throw an error from the land of COM talking about, “Why did you pull the rug from underneath me?”
For simple applications, it is true, it can be ignored. The major purpose for App.xaml is for holding resources (style, pens, brushes, etc.) that would would like to be available through out all of the windows in your application.
It is true. App.Xaml is some sort of central starting point. You CAN use it, or you CAN start your first window (it is defined in the app.xaml) manually. There are some lifetime events there centralls (like application start).
Storing resources that are used across the whole application.
Application is the root of the logical tree.
It is like Global.asax if you are coming from an ASP.NET background. You can also use it to share resources throughout your application. Comes in pretty handy for resource sharing.
App.xaml is a major part of wpf application.
It contains major four attributes
1.X:Class->used to connect you xaml and code-behind file(xaml.cs).
2.xmlns->To resolve wpf elements like canvas,stack panel(default one).
3.xmlns:x->To resolve XAML language definition.
4. StartupUri->To give start window when application is launching.
++++++++
App.xaml is the declarative starting point of your application. Visual
Studio will automatically create it for you when you start a new WPF
application, including a Code-behind file called App.xaml.cs. They
work much like for a Window, where the two files are partial classes,
working together to allow you to work in both markup (XAML) and
Code-behind.
App.xaml.cs extends the Application class, which is a central class in
a WPF Windows application. .NET will go to this class for starting
instructions and then start the desired Window or Page from there.
This is also the place to subscribe to important application events,
like application start, unhandled exceptions and so on.
One of the most commonly used features of the App.xaml file is to
define global resources that may be used and accessed from all over an
application, for instance global styles.
+++++++++
Source : http://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Here is an updated answer in case people are still looking.
There is this excellent article on WPF, and the link specifically puts you at the App.Xaml point to begin teaching you the things you can do with it.
WPF is easy for the first very simple app or two. However, due to the increased flexibility of the framework, you need these types of tutorials to help you understand what can be done from where (in the various application files).
https://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Good luck.
I have a Silverlight 3 App that became quite big over the time. So I began to try to break it in several smaler Applications that will be dynamically loaded in my Main Application on demand. But I run into a strange problems with my VS 2008.
When I add a new Silverlight Application project to my solution and copy User Controls from my old Main Application into this new project it happens from time to time (about twice a day) that the XAML files and their code behind files loose their association. When this happens and I try to build the project, the compiler complains that he cannot find all the Ccontrols like buttons, labels etc. in the code behind files that I added to the class in the XAML-file. And the build fails of course.
The only workaround that I found so far is to add another Silverlight Application project and move all the content from the first added project to it. Than everything works fine for a while until the problem occurs again.
But that's not really a solution.
Any Ideas what happens here and what i can do?
Best Regards,
Rocko
I have seen issues like this before when changing the namespaces on controls in silverlight. The issue crops up when you don't change both the namespace on the control class, and the full name of the class in the x:class attribute on the root element of the control.
Not sure if this fits your situation or not, but it's the only time I've run into similar issues.
I'm writing a prism application and would like to integrate Ribbon library in it. I want a Ribbon Window that would be used as a Shell with office-like tabs and tab groups. The modules should be loaded on demand depending on the tab selected by user. I don't want the tabs to be located in a region if this is avoidable. So I created a Ribbon window and some regions and get all kind of errors (cannot resolve dependency object, etc.). Is there somewhere a good example of such application or a tutorial? How to load the modules depending on the user's choice?
I started this thread but I didn't get an answer that could help me.
Thanks for any help and suggestions.
Have you implemented a RegionAdapter for the Ribbon? (I'm guessing you're trying to fill the Ribbon dynamically with a Region attached property)
See this link for details.
Make your shell a RibbonWindow and if you need commands over the whole application you can create applicationcommands.
I am considering building a application using PRISM (Composite WPF Guidance/Library). The application modules will be vertically partitioned (i.e. Customers, Suppliers, Sales Orders, etc). This is still all relatively easy... I also have a Shell with a main region were all the work will happen but now I need the following behavior: I need a menu on my main Shell and when each one of the options gets clicked (like customers, suppliers, etc) I need to find the module and load it into the region (Only 1 view at a time)?
Does anybody know of any sample applications with this type of behavior? All the samples are more focused on having all the modules loaded on the main shell? And should my menu bar also be a module?
[UPDATE] How do I inject a module into a region based on it being selected from a menu? All the examples show that the module injects the view into the region on initialize? I need to only inject the view if the module is selected on a menu?
Yes PRISM will help you out here.
A number of things here worth mentioning.
RE: Is Prism right for me?
You can load a Module on Demand. PRISM has the capabilities of loading a module at RunTime, so in your case if you bootup the said solution using Shell and ModuleA. Your user then triggers an event (ie Menu choice) it can then allow you to dynamically load ModuleB and then inject that into play. To be clear though, you really need to sit down and do your homework here as you need to ensure ModuleB doesn't have any of its own dependencies on other modules etc (typically its wise to use an Infrastructure Module. I've used techniques where i have a manifest of modules that i lookup in XML that lists its absolute dependencies and then I make sure they are loaded first, then I load ModuleB).
See Load Modules on Demand via PRISM help docs (Development Activities). Also lookup Prepare a Module for Remote Downloading
RE: Injecting a view at runtime
To inject a View into a Region via Menu is a simple case of accessing the IRegionManager and then adding it. To do this, make sure in your Constructor for the said ViewModel/Presenter/Controller you're using put:
MyConstructor(IRegionManager regionManager, IUnityContainer container)
As with PRISM you can pretty much add any object you want into your construct and PRISM will ensure it arrives there on time and on budget (hehe).
From there its the normal approach you'd take with adding a view... eg:
IMyViewInstance myViewInstance = this.container.Resolve<IMyViewInstance>();
IRegion myRegion = this.regionManager.Regions["YourRegion"];
myRegion.add(myViewInstance);
myRegion.Active(myViewInstance);
And all should come together! :)
Note:
Make sure you set a local reference to the container and regionManager at Construct (this.container = container etc).
If you're not sure where the above namespaces exist, right click on IUnityContainer for example and let Visual Studio RESOLVE it (right click menu)
Put the Add logic into your Menu Event that or use a central method - whichever blows your hair back :)
Scott Barnes - Rich Platforms Product Manager - Microsoft.
Just finished watching Brian Noyes on Prism at dnrTV. This answered all my question...
It's not clear what you mean saying "find the module and load it into the region". You can load module's view and add it to shell. Composite UI app block and CompositeWPF are built on top of the IoC pattern. It means that your modules should inject their menu items in shell's menu strip or subscribe to events generated by shell.
You could have your main region be a ContentControl, this way only 1 view will be active at a time.
You can also load your modules "On Demand". There is a Quickstart that shows you how to do this. You should also keep in mind that if the module was already initialized once, initializing it for a second time will not execute the Initialize() method on the module.
It might be useful that when you click on the menu, this will load the module on demand (which will not load the view yet) and then you can fire an event through EventAggregator, so the module can now add the view (use the named approach for not adding the view twrice) and the Activate the view (which will make sure the view is shwon in the region).
Hope this helps,
Julian
to save you time, check John Papa's Presentation Framework article. It will be more easy if you have 3rd object(Screen Conductor) to handle your screens in showing or hiding from regions.