Application Wide WPF Namespace - wpf

In my WPF Application I find myself adding the following namespace to every control:
xmlns:Core="clr-namespace:MHA.Modules.Core;assembly=MHA.Modules.Core"
Is there a way I can only add this namespace once and that it will be available application wide?
Thanx

Sadly there is no way that I know off to do this..
What you could do instead is use the XmlnsDefinitions which would tidy this up considerably and would also give you abit of of future proofing if you decide to add something new to the core but in a different name space.
in your AssemblyInfo file, add the following
[assembly: XmlnsDefinition("COMMON-URL", "MHA.Modules.Core")]
you can also add multiple namespaces under one URL.
then you could reference it in your XAML like
xmlns:Core="COMMON-URL"
for more information - see http://zachbonham.blogspot.co.uk/2010/04/organize-xaml-namespace-declarations.html
cheers.
ste.

Related

How to use oxyplot with DataBinding in wpf

I'm trying to use the oxyplot library in my WPF application. also, I'm using the MVVM pattern. one of the main parts of this pattern never uses "UI" specific in the "ViewModel" project. but when I look at the examples for this library, I see people are referencing oxyplot in their "ViewModels" by this: using oxyplot;. now I have this question. how should I use this library with the MVVM pattern? now I have installed the package in my "view" project by the NuGet package manager, should I do the same for my "ViewModel" project? I think this is not good because by installing it in "ViewModel" I'm breaking the MVVM pattern. but how can I access oxyplot classes from my "ViewModel"?
Thanks in advance.
I was expecting to use the oxyplot by the MVVM pattern but now I'm mixed up :(
your approach might work but I think you also need a value converter to convert between classes in "View" and "ViewModel" because they belong to different assemblies and also you may end up with namespace conflicts between "oxyplot" in "ViewModel" and "oxyplot" in "View" so you also have to do extra thing, for example, renaming the "oxyplot" namespace in "ViewModel" I think.
The Best solution is to add "Oxyplot.Core" to your "ViewModel" and everything works fine and there is no need for extra work.

Best Starting Point for WPF Revit Add in

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.

How to find name of my XAML file in my WPF application at run time

I am working on very complex WPF application which has many resource files because of which XAML doesn't load at design time. I want to find names of XAML files, at run time. I am trying to use snoop but not able to find name of XAML file. Please help
Using Snoop won't give you file names but you should be able to locate some type names (i.e. UserControls, custom controls, etc) or elements with x:Names by looking through the visual tree view near where you're trying to get to after using the Ctrl-Shift mouse-over shortcut. Searching for either usages of types (in the case of controls) or using Find in Files on all solution *.xaml files should help you find the elements you're looking for.
Usually I do this by starting at a high level of the UI (for example MainWindow)
and the draw the components on paper that I find there, especially the grids.
Then I try to figure out where the elements of my application are in that view.
If you have multiple views, this can be somewhat timeconsuming. But if you
cannot just click through the designer windows, this is one of the fastest
possible ways to do it.
Okay, if you only have minor changes, you can try to find the element that
you want to change by using string search.
Find the label you want, if it is a resource string, find the usage of it.
If you have a complex MVVM application, you can start by investigating
the ViewModels used. They can be a better starting point than the View
itself.
-edit-
WPF Inspector can give you good hints on where to search.
You can get it here: WPF Inspector home
If you are looking for it for your own needs, you can call BaseUriHelper.GetBaseUri(v) on any visual and it will give you the Uri of the resource that your visual comes from. From this Uri you can get the origin xaml file

How to avoid XAML namespace import in every Window

Is it somehow possible to avoid xmlns:Engine="clr-namespace..." if i need the same namespace in each of my application windows?
Thanks
I'm agree with HCL, I think it can't be done and adding the namespace will not consume more resources.
I will give you an alternative. You can change the the window template (or create one of your own) to make it include the namespace for you.
In my computer, for VS2010, the path of the template is:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ItemTemplates\VisualBasic\WPF\3082
Note that one is for vb.Net, there is a CSHARP directory as well.
Edit:
As far as I Know, the templates are for each computer, not for each project, but when you edit the template you can use conditionals, for example:
$if$ ($targetframeworkversion$ >= 3.5)using System.Linq;
You can use the $rootnamespace$ constant to check for a specific project and then add the namespace or not. Maybe a constant with the current project name exists, i don't know, but $rootnamespace$ should be enought for this pourpose.
If it's your own the sourcecode to the assembly you using in the Engine namespace you can accually totaly remove the prefix requerment and the demand of adding something. With this little trick you just append your own namespaces to the xaml namespace (that allready is included).
In your "Engine" project (not the project where you have the xmlns:Engine line, can't be the same project where you use it, it will not work then) make sure you have the WindowsBase reference added and then add the following in the the AssemblyInfo.cs/AssemblyInfo.vb file (c#: found in the Properties folder) (vb: you need to use the "Show all Files" button and then you will find it in the My Project folder):
c#:
[assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "The.Class.Namespace")]
vb:
<Assembly: XmlnsDefinition("http://schemas.microsoft.com/winfx/2006/xaml/presentation", "The.Class.Namespace")>
You can do this several times if you project have classes in more then one namespace you wanna use in the other projects xaml.
No, there is no way to avoid this. However declaring a namespace does not mean that it consumes resources (at runtime).

IlMerge Silverlight Class Library with Custom Controls

I am trying to merge all the assemblies of an class library in a single .dll file.
I can merge all the assemblies using the Ilmerge but is that when I use the merged dll in a Silverlight application I am having trouble when a template is apply to my control and binding problems if I use a control that inherits with UserControl.
is there any solution to solve this problem?
The problem is that when the initial dlls are built the Xaml in the project is added as a resource in the dll. The code generated to load this xaml will look something like this:-
System.Windows.Application.LoadComponent(this, new System.Uri("/SilverlightLibrary1;component/MyControl.xaml", System.UriKind.Relative));
Note how the name of the dll forms part of the Uri need to fetch the xaml. I doubt IlMerge is able to spot that and fix it up. Hence once merged the Uris cannot be found.
A resolution for this is probably uglier than multiple references or simply creating another project that links all the code files involved.

Resources