Referring to this question and this question, the solutions in the accepted answers are working, but in the project i want to apply, no binding or trigger is working. There is no error, the triggers etc simply do not respond.
The code is huge, with a complicated layout using many grids and panels and a ribbon. Source of binding and triggers and target are in different panels (source in ribbon, target in grid below). I know the code is correct, my question is:
What is the checklist? What are the things i need to look at to ensure that triggers and bindings are working.
If source and target are in different panels, is there something different in their implementation (like going from ribbon to the parent (main grid created by default)) and then finding the target in the children (grid)?
I can print on console if i write code-behind, but is there a way to debug triggers and bindings?
You can always look i your output window for binding failures. This might prove helpful to you to test your bindings and trigger failures -
http://bea.stollnitz.com/blog/index.php?s=presentationtrace
I've also had success debugging triggers with this technique:
http://www.wpfmentor.com/2009/01/how-to-debug-triggers-using-trigger.html
Related
The WPF designer has a tough job to do. In order to show you a life view of your screen or component it has to execute code but, since you do not control the designer, it has to do this without producing any side effects.
So how does it do that? What are the rules around execution?
What if the view's code-behind code does logging to a file or a service?
What if the code-behind calls MessageBox.Show?
What if the code-behind doesn't have an empty default constructor?
I've hit situations before where I had a default constructor that was checking GetIsInDesignMode and creating and assigning a DataContext if false, and still the designer wasn't rendering correctly. Is there some sort of stack-depth limit?
What are the limitations?
it has to do this without producing any side effects
No, the designer is not that smart. If IsDesignTimeCreatable is specified, it will execute all code in a public parameterless constructor and in properties accessed by bindings. Specifically, it will popup message boxes, write to files, etc -- or throw exceptions trying (just try it yourself).
If you don't have a public parameterless constructor, it can't create an instance, so no code will run.
Regarding your question about "stack depth limit", I know of no such limitation. If you have a specific case where it's not working, I suggest you ask a specific question about that case.
In most cases where the designer fails it is because of an exception or other non-data-related problems (such as missing design-time resources). You should definitely guard code you don't want called during design-time using DesignerProperties.GetIsInDesignMode (I usually add a property IsInDesignMode to the base view model).
This is not exactly answering your question, but to be honest 'how does it work' is not a very specific question.
However rather than dropping this check in to your code-behind, are you aware that you can add something like this to your Xaml?
d:DataContext="{Binding Source={d:DesignInstance Type=namespace:className, IsDesignTimeCreatable=True}}"
This means that you can make a design-time version of your class, e.g. CalculatorDesign :
ICalculator, reference that in the Xaml, and each time you change and compile the design-time class the view will update within VS without running any code or having complicated logic in code-behind.
I'm trying to build a maintenance form in WPF, using Telerik's WPF controls. The idea is to have a grid and a form that are bound to the same collection. Changes to the grid should be immediately reflected in the form, and vice versa. An online example using Telerik's Silverlight controls is here.
My specific problem is that when I enter a new record (by clicking on the "Add" icon in the upper-right of the DataForm), the record is added to both the grid and to the form's collection, but it seems to break the synchronization. The new row in the grid stays highlighted, like the grid thinks it's not done being edited, and while changes to the current record in the form are reflected in the grid, changes to the current record in the grid are no longer being reflected in the form.
But my real problem is more general than that. WPF controls, like Telerik's, are heavily dependent on binding, and in having what they bind to support specific behaviors. In this case, the underlying record needs to support INotifyIEditableObject, so that when the user hits the Cancel button on the form, the EditCancel method on the record can be called. Which is then responsible for setting its properties back to what they had been, and then raising a NotifyPropertyChanged event, so that controls that are informed that they have been so set.
When I didn't have EditCancel working right, I would hit cancel on the form and the values in the grid would not be changed. My guess as to what is going on with the inserts is that something in either my collection or by records doesn't support whatever it is that makes this work. The grid doesn't know that the form has finished editing the record because either my record or the collection hasn't told it.
And here's the real question: how can I find out what these third-party controls are expecting? Telerik's RadGrid can be bound to pretty much anything that can be IEnumerated. But all this neat enhanced functionality depends upon being bound to collections that are very much more specific. I don't get errors, when I bind to a collection that lacks facilities that are needed for certain functions to work, I just get a control that doesn't work.
How can I tell, when working with someone else's control, for which I do not have source code, what functionality it requires, in the objects it binds to?
Your best bet would be to browse Telerik's documentation or ask on their support forums
If that doesn't work, I like to use Snoop for debugging WPF's Visual Tree and Reflector for looking through compiled libraries
I'm working on a large WPF project using MVVM. We're currently still deciding the extent to which we'll use code-behind, but so far we've gotten along fine with none at all (except for InitializeComponent on windows). However, I recently started using typed DataTemplates to apply views to my view models, and it seems these views, like windows, do not work without the InitializeComponent call, when, according to this article, I thought they would. The DataTemplate just declares a view. When I delete the view's code-behind file, the view model renders completely blank. When I leave it in, it's fine. Any ideas why I might be seeing this behavior?
First, you may be overlooking something important: I used that article heavily when learning MVVM/WPF as well, and I never thought it suggested eliminating InitializeComponent calls from the View.cs.
In fact, doing a quick search reveals the following (under Relaying Command Logic) [emphasis mine]:
Every view in the app has an empty
codebehind file, except for the
standard boilerplate code that calls
InitializeComponent in the class's
constructor.
I've been applying the same pattern you describe while leaving the default code-behind for each view in place, and so far it's smooth sailing. :)
Further: If you check out the definition for the default InitializeComponent(), you'll see that the generated code contains the following statement:
System.Windows.Application.LoadComponent(this, resourceLocater);
I haven't tested to make sure this is the case, but I'll wager a fiddle of gold against your soul that preventing that line from executing is going to affect the rendering of your view... ;)
According to djacobson, even the solution by Josh Smith that I referenced in my question cannot render its views without the code-behind, so the line stating this can be done is misleading. It seems the only way to avoid code-behind for your views is by not putting them into UserControls at all, but just keeping the XAML directly within a < DataTemplate > tag.
Scenario: I have a (numeric) textbox, a button, and a label. When the button is clicked I'd like the label to "animate" to the numeric value in the textbox (like a spinning dial)
Given:
a) that animations in storyboards cannot have databindings (because they are not FrameworkElements)
b) the lack of triggers in Silverlight
What is the best, and with least coupling of the view model to the view's storyboard, way to update the target animation value and start the animation when the button is clicked?
Note: The scenario is conceptual, so don't concentrate on the specifics of 'animating' numbers or anything
If your goal is strictly to reduce the code-behind in the view I think that an attached behaviour on the Label would work for this. The attached behaviour on the label would expose the number to be animated to and when this number changes an animation (in code) would be run to animate from the old value to the new value.
One drawback is that your animation is now in code, unless you store a templated (just has fake values to start with) version of it in a resource file somewhere where you can load it as needed and replace the templated values.
This article from Josh Smith seems to be the authority on Attached Behaviours;
http://joshsmithonwpf.wordpress.com/2008/08/30/introduction-to-attached-behaviors/
I recently had to solve a similar problem in an MVVM application. My problem was that I needed to animate a container's height from zero to auto. Since Auto is a dynamic value I recognized that the animation (or storyboard) would need to be built (or manipulated) on demand. The solution that I put in place involved using view code-behind to update and fire the animation.
This isn't the most MVVM-friendly approach; however, animations in WPF can be tricky in XAML. Since this solution is really just a workaround for a XAML limitation it seems okay to tie the code directly to the view. Likewise, if the views were mocked then there would be no framework elements to animate, so it really wouldn't make sense to place this code on the VM side.
Does anybody have a better approach?
I have a question regarding a ComboBox in silverlight and it's selected item.
I would like to determine what triggered the SelectionChangedEvent, was it the user selecting a new item in the list or was it programatically set?
While ideally I would like to solve this using the CommandPattern (I am essentially using a modified RelayCommand (http://joshsmithonwpf.wordpress.com/2008/11/17/emulating-icommandsource-in-silverlight-2/). I am open to other suggestions.
I have also played around with the SelectionChangedEventArgs, which has an OriginalSource property, which upon first inspection may appear to help, however it is null (regardless of the manner in which the item was selected.)
Any ideas, other than setting an internal flag? :)
Thanks
Unfortunately this is a tough thing to determine, since the framework works pretty hard to simply bubble up any changes or user events in this situation as that selection changed event.
If you really need to, you could write a simple ComboBoxWrapper that is effectively the flag you're talking about - so you could derive from ComboBox, try overriding or hiding the CLR setter for SelectedItem, and then maintain state that way.
Any particular scenario in use here? There may be another way to approach a solution.