I'm using the DataGrid2D component (installed via NuGet) to allow me to bind a 2D array to a datagrid in a .Net Core 3.1 WPF project using Prism.
https://github.com/GuOrg/Gu.Wpf.DataGrid2D/blob/master/README.md
Everything works it's just that the designer breaks and VS gives me the following warning for the code snippet shown below:
The Attachable Property 'Array2D' was not found in type 'ItemSource'
Here's the alias I included in the top of the xaml page:
Any ideas how to resolve this?
Sadly I think this may be just one of countless bugs in the WPF designer.
Does it work when you run it?
You can try a sad loop of closing vs, git clean, rebuild etc. and maybe it goes away.
I am trying to start using Telerik's RadDataFilter.
xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"
...
<telerik:RadDataFilter Name="radDataFilter"
Source="{Binding FirstEntries}"/>
But I get an error:
The tag 'RadDataFilter' does not exist in XML namespace 'http://schemas.telerik.com/2008/xaml/presentation'. Line 44 Position 10.
Could you please explain to me what I am missing? Thanks.
Does your project have references to Telerik.Windows.Controls.dll and Telerik.Windows.Controls.Data.dll? The Telerik documentation for the RadDataFilter mentions that both of these references are necessary.
I was able to reproduce the error you were getting by trying to build a project that uses a RadDataFilter but which has references to only one of the two assemblies mentioned. When I added a reference to the second, and rebuilt, the error went away.
(Admittedly, this was with the Silverlight version of the controls. However, the WPF and Silverlight versions of the Telerik RadControls are built from the same source code, so I expect that the WPF version of the controls will behave the same.)
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've been trying to get to the bottom of an issue with binding the SelectedItem of my ComboBox, and since I've had no success thus far, I started looking at ways to get more detailed debugging information by setting PresentationTraceSources.TraceLevel=High for specific bindings. Unfortunately, after doing so I don't see any related items in my Output window under the Debug category.
I'm using Visual Studio 2010, and my project is a WinForms project with heavy usage of interop using ElementHost to host WPF content. All related projects are currently being built for .NET 3.5. Any thoughts or suggestions that may lead me to the solution of seeing the extra trace information in the output window will be appreciated.
Below is a snippet of the code I'm using.
<ComboBox xmlns:diagnostics="clr-namespace:System.Diagnostics;assembly=WindowsBase"
SelectedItem="{Binding Path=MyCollection.SelectedItem, Mode=TwoWay, diagnostics:PresentationTraceSources.TraceLevel=High}"
ItemsSource="{Binding MyCollection, diagnostics:PresentationTraceSources.TraceLevel=High}"
SelectedValuePath="Value"
DisplayMemberPath="Value.DisplayName" />
It's a setting in the Visual Studio 2010:
Tools -> Options -> Debugging -> Output Window -> WPF Trace Settings -> Data Binding -> set to Warning (or whatever you like).
Standard was Off.
This solution worked for me.
Make sure that your DataContext is not null. If it is, no information will be logged to the output window
Also see this answer here -
https://stackoverflow.com/a/50282982/3984575
Summary: make sure you are not overriding the settings with a line like this in your code -
System.Diagnostics.PresentationTraceSources.DataBindingSource.Switch.Level = System.Diagnostics.SourceLevels.Critical;
I am working without expression blend and just using the XAML editor in vs2010. The wisdom of this aside, I am increasingly seeing a need for design-time data binding. For simple cases, the FallbackValue property works very nicely (Textboxes and TextBlocks, etc). But especially when dealing with ItemsControl and the like, one really needs sample data to be visible in the designer so that you can adjust and tweak controls and data templates without having to run the executable.
I know that ObjectDataProvider allows for binding to a type, and thus can provide design-time data for visualizing, but then there is some juggling to allow for the real, run-time data to bind without wasting resources by loading loading both the design time, dummied data and the runtime bindings.
Really what I am wanting is the ability to have, say, "John", "Paul", "George", and "Ringo" show up in the XAML designer as stylable items in my ItemsControl, but have real data show up when the application runs.
I also know that Blend allows for some fancy attributes that define design time binding data that are effectively ignored by WPF in run-time conditions.
So my questions are:
1. How might I leverage design-time bindings of collections and non-trivial data in the visual studio XAML designer and then swap to runtime bindings smoothly?
2. How have others solved this design-time vs. runtime data problem? In my case, i cannot very easily use the same data for both (as one would be able to with, say, a database query).
3. Are their alternatives to expression blend that i could use for data-integrated XAML design? (I know there are some alternatives, but I specifically want something I can use and see bound sample data, etc?)
Using VS2010 you can use Design-Time attributes (works for both SL and WPF). I usually have a mock data-source anyway so it's just a matter of:
Adding the namespace declaration
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
Adding the mock data context to window/control resources
<UserControl.Resources>
<ViewModels:MockXViewModel x:Key="DesignViewModel"/>
</UserControl.Resources>
Setting design-time data context
<Grid d:DataContext="{Binding Source={StaticResource DesignViewModel}}" ...
Works well enough.
As an amalgam of Goran's accepted answer and Rene's excellent comment.
Add the namespace declaration.
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
Reference your design time data context from code.
<Grid d:DataContext="{d:DesignInstance Type=ViewModels:MockXViewModel, IsDesignTimeCreatable=True}" ...
I use this approach for generating design time data with .NET 4.5 and Visual Studio 2013.
I have just one ViewModel.
The view model has a property IsInDesignMode which tells whether design mode is active or not (see class ViewModelBase).
Then you can set up your design time data (like filling an items control) in the view models constructor.
Besides, I would not load real data in the view models constructor, this may lead to issues at runtime, but setting up data for design time should not be a problem.
public abstract class ViewModelBase
{
public bool IsInDesignMode
{
get
{
return DesignerProperties.GetIsInDesignMode(new DependencyObject());
}
}
}
public class ExampleViewModel : ViewModelBase
{
public ExampleViewModel()
{
if (IsInDesignMode == true)
{
LoadDesignTimeData();
}
}
private void LoadDesignTimeData()
{
// Load design time data here
}
}
Karl Shifflett describes an approach that ought to work equally well for VS2008 and VS2010:
Viewing Design Time Data in Visual Studio 2008 Cider Designer in WPF and Silverlight Projects
Laurent Bugnion has a similar approach that focuses on Expression Blend. It might work for VS2010, but I haven't confirmed this yet.
Simulating data in design mode in Microsoft Expression Blend
Maybe the new design-time features of Visual Studio 2010 and Expression Blend 4 are an option for you.
How it works is shown in the BookLibrary sample application of the WPF Application Framework (WAF). Please download the .NET4 version.
Similar to the top rated answer, but better in my opinion: You can create a static property to return an instance of design data and reference it directly from XAML like so:
<d:UserControl.DataContext>
<Binding Source="{x:Static designTimeNamespace:DesignTimeViewModels.MyViewModel}" />
</d:UserControl.DataContext>
This avoids the need to use UserControl.Resources. Your static property can function as a factory allowing you to construct non-trivial data types - for example if you do not have a default ctor, you can call a factory or container here to inject in appropriate dependencies.
Using Visual Studio 2017 I have been trying to follow all of the guides and questions such as this and I was still facing a <ItemsControl> which simply did not execute the code I had inside the constructor of a DesignFooViewModel which inherits from FooViewModel. I confirmed the "did not execute" part following this "handy" MSDN guide (spoiler: MessageBox debugging). While this is not directly related to the original question, I hope it will save others a lot of time.
Turns out I was doing nothing wrong. The issue was that my application needs to be built for x64. As the Visual Studio is still in 2018 a 32-bit process and apparently cannot spin a 64-bit host process for the designer part it cannot use my x64 classes. The really bad thing is that there are no errors to be found in any log I could think of.
So if you stumble upon this question because you are seeing bogus data in with your design time view model (for example: <TextBlock Text="{Binding Name}"/> shows up Name no matter you set the property to) the cause is likely to be your x64 build. If you are unable to change your build configuration to anycpu or x86 because of dependencies, consider creating a new project which is fully anycpu and does not have the dependencies (or any dependencies). So you end up splitting most or all but the initialization parts of the code away from your "WPF App" project into a "C# class library" project.
For the codebase I am working on I think this will force healthy separation of concerns at the cost of some code duplication which is probably net positive thing.
I liked jbe's suggestion, specifically to look at how they do it in the WAF framework sample apps - they use separate mock/sample view models in a DesignData folder and then have a line like this in the XAML:
mc:Ignorable="d"
d:DataContext="{d:DesignInstance dd:MockHomeViewModel, IsDesignTimeCreatable=True}"
(where dd points to the .DesignData namespace where MockHomeViewModel lives)
It's nice and simple (which I like!) and you can inherit from the real VMs and just provide dummy data. It keeps things separate as you don't need to pollute your real VMs with any design time only code. I appreciate things might look quite different for a large project utilising IOCs etc but for small projects it works well.
But as joonas pointed out, it seems not to work with x64 builds in VS2017 and this still seems to be the case with VS2019 (I'm using V2019 16.6 Community edition). It's not fiddly to get working to start off with but can cause some head scratching when after making a change (or as is usually the case, several changes!) it suddenly stops working.
For anybody trying it, I would recommend creating a new simple WPF project (say one view, one view model, one mock vm) and play around with it; get it working and then break it. I found sometimes, no amount of solution cleans and rebuilds would fix it, the only thing that worked was closing VS down and restarting, and suddenly my design time data came back!