I have various custom behavior classes defined which derive themselves from ControlBehavior class. The ControlBehavior class is missing in .net 4.
ControlBehavior was part of WPF Toolkit before it was released in .net 4.
So how to proceed?
You'll probably need to grab the source of the WPFToolkit and implement your own version of that (behavior) class.
Related
Can anyone suggest a pattern to open/manage popup windows in a WPF MVVM(Prism) .Net Core application? I was using Prism's PopupWindowAction before. Now XAML Behaviors for WPF are ported to .Net Core (https://weekly-geekly.github.io/articles/433334/index.html), but Interaction.Triggers doesn't accept InteractionRequestTrigger.
It's called IDialogService, see this issue at Github.
I have to use VisualStateManager class in my WPF window, but as I have referenced the assemblies of both WPF Toolkit and PresentationFramework.dll in my project, C# is not able to resolve the VisualStateManager class and gives the compile error like -
"The type exists in both 'PresentationFramework.dll' and 'WPFToolkit.dll'" and I am not able to proceed.
How to tell C# compiler to use VisualStateManager class from either of the assemblies and get the project to compile successfully?
Since the .NET4.0, the WPF Toolkit has been included in the framework. You should be able to remove WPF Toolkit, update some namespaces and the application still compile.
This is an approach we have taken in a project where we recently upgraded from .NET3.5 to .NET 4.0
Best regards,
I had a similar problem, not to do with the VisualStateManager but with the TemplateVisualStateAttribute I was using for one of my custom classes.
Changing the WPFToolkit project reference alias fixed this for me, as per this question
I ran into the same problem, I can not remove the ToolKit because I need the AutoCompleteBox control, and I don not want to include and modify the toolkit source code; so the solution I used was using an extern alias for the toolkit reference.
To do this in Visual Studio right click on the WPFToolkit reference and select properties >> then change the "alias" field to WpfToolKit or any alias of your choice.
I have a WPF application and a Silverlight application. They are both used to display a map and share some of the same functionality.
I have created a Silverlight class library project in order to stay DRY. I'm referencing this from both Silverlight and WPF. It contains some utility methods that are useful in both projects. For example, I have this method:
public static void CenterText(TextBlock name, Polygon poly)
The silverlight project has no problem with this. However, I get the following error when calling this from my WPF application:
The type 'System.Windows.Shapes.Polygon' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'
However, I have this line at the top of the file:
using System.Windows.Shapes;
so WPF can see the Polygon class perfectly fine.
My guess is that the silverlight class library uses a version of the framework which is not compatible with the version that the WPF project is using.
So the question is, am I stuck rewriting exactly the same code in my WPF application or is there some way I can share between the two?
Thanks!
You are right, Silverlight uses a completely separate version of the framework. It's much, much smaller than event the .NET client runtime.
This means you can't mix WPF and Silverlight assemblies in the same application.
I ran into this error because I had downloaded the Expression Blend SDK for Silverlight instead of what I SHOULD have downloaded: Microsoft Expression Blend Software Development Kit (SDK) for .NET 4. It can be found on MSFT's website, here:
http://www.microsoft.com/en-us/download/details.aspx?id=10801
As soon as I downloaded the Expression Blend SDK for .Net, removed all of the Blend SDK for Silverlight references, and added those same references as Blend for .Net, I was up and running.
In Silverlight the class is in System.Windows.dll while in WPF it is in PresentationFramework.dll the library tries to get a hold of the Silverlight assembly which is not referenced by default in a WPF application.
We have a solution with two different projects, one with the requirement that it be done using the .Net 2.0 framework. The other uses .Net 3.5, and we follow MVVM, though I suspect this is less about MVVM than good patterns.
The .Net 2.0 has several different objects (let's say of type Fruit) which could potentially require a different WPF user interface to edit the class property values. For now, I am just working on the first one. The .net 3.5 project is what users actually run and edit with.
My first thought was, when we create the Fruit subclass (Apple, in the constructor have a Func parameter which returns the call to create the editing dialog. The other fruits, which do not have editing dialogs implemented yet, would simply have a Func parameter which returns a "Editing not supported" editor dialog. But Funcs are not supported in 2.0.
My next thought is, to add attributes to the .net 2.0 classes which refer to the .Net 3.5 classes which the .net 3.5 project could then create instances of, using reflection. But this seems messy.
I could create a CreateFruitEditor class in the .net 3.5 project that just checks the Fruit type and creates the appropriate editor window, but that would eventually result in a big multi-line if statement checking types (with the assumption that the fruits are quite different in editing.)
So...the .net 2.0 project classes must somehow inform my .net 3.5 project of what .net 3.5 classes to use for editing the .net 2.0 classes.
You are mixing concerns here. Treat your .NET 2.0 classes as your Model and wrap or replace them with ViewModels for your views.
I've been trying to use the WPF toolkit in a WPF application that I'm deploying internally at my company, but the toolkit needs .Net 3.5 sp1. The only difference between sp0 and sp1 for the toolkit is the MultiSelector class that the DataGrid uses.
My question is, does anybody know of a workaround for this so sp1 isn't required? Is there a custom MultiSelector class that I could use?
I know the toolkit was started before sp1 but I'm not sure what kind of progress was made before the MultiSelector was added.
I've tried using ILDasm to get the IL code for the MultiSelector class and generate my own, but I haven't had any success as it implements features from internal parts of the Selector class in PresentationFramework.dll.
Any help on this matter would be great, and upgrading everybody to .Net 3.5 sp1 is currently not an option.
If anybody knows about another free DataGrid control that could be used in place of the WPF Toolkit, it would be appreciated as well.
Thanks,
-Noah
You won't be able to use a different MultiSelector, as the one in the toolkit has a hard reference to the type in the SP1 version of the framework. Even if you did create your own MultiSelector for use, you would have to change the grid control to use yours, which would require decompiling it into source, modifying it, and then recompiling it, which beyond being a PITA, is probably a violation of the EULA as well.
As for a free data grid alternative, I would check out Xceeds DataGrid for WPF. The Express edition is free:
http://xceed.com/Grid_WPF_Intro.html