A few of my silverlight pages should provide a custom error message depending on whether an error occurred and what the error is.
I have a custom control that will present the user with the error, however, my question is:
Would it be better to add this control into the XAML and just set it as collapsed or visible (depending on whether an error occurred), or create and destroy it dynamically at runtime in the code-behind? What are the implications of each?
Thanks
Since one would assume that the display of error information is rare there isn't a lot of difference between the approaches. You should go with the simplest and easiest to understand solution. That would likely be using the collapsed error XAML
Related
I have a resource dictionary with 12.000 lines.
If I activate First Chance Exceptions I get some XamlObjectWriterException with an inner of type NotSupportedException claiming that it cannot create a DependencyProperty from text 'Padding' or 'Foreground'.
Line number and position are set to 0 so I don't know where the error is coming. The exceptions are coming from the loading of the resource dictionary on app startup, before using the styles anywhere.
Is there a way to find what style is (are) the offending ones?
Is there a way to find what style is (are) the offending ones?
I am afraid the XAML processor doesn't give this detailed information. But at least it gives you a clue.
Search for all places where you set the Foreground property and comment them out one by one and compile and run until you have narrowed down the issue. I am afraid there is no easier way unless you are able to guess in which resource the error may be.
We have some derived control classes which have specific data. And these controls also set the data error info and binding to some specific property. For example, if the property IsNew (providing it exists) is true then the background is highlighted.
Now I want to know, what if I use these controls and bind to some objects which do not expose such property as IsNew? Will it affect the performance for Release version?
The error in itself will not cause any additional performance issues, but the constant Binding checks will and do cause some very minor (practically unnoticeable) performance issues. This is one of the many reasons why WPF performs less well than many other languages. However, these checks will go on whether you have errors or not.
The only time that having errors will actually slow down your program is when your are using the PresentationTraceSources to output information into the Output Window of Visual Studio or worse still, into an external trace file. However, even in these cases, it is unlikely that you will find a noticeable drop in performance, unless you have set the WPF Trace Settings to the most verbose setting of Verbose.
I've read a lot of questions on SOF and links (for example http://www.beacosta.com/blog/?p=52)
But is there easy way to know what exact file I should look into when Binding fails?
If we have one Application and a lot of forms, it can be difficult too.
Have you tried checking "Thrown" for the exception in question in the Debug->Exceptions menu.
E.g. if you get
System.Windows.Data Error: 35 : BindingExpression path error ...
Then you can tell the debugger to break on it by checking "Thrown" under Common Language Runtime Exceptions -> System.Data -> System.DataException. This is however, only useful if the exception originally occurs in your code. Other exceptions, such as binding to non-existing properties and so on will silently fail and only print in the Output window. There is some discussion on http://visualstudio.uservoice.com for improving XAML debugging
I just found the most WONDERFUL post when looking for this. It is a listener that listens for binding errors and throws up a message box with details. It only works when running from within Visual Studio, so you won't show it to your users. Two steps - copy the class into your project, and set the listener in your main window.
http://tech.pro/tutorial/940/wpf-snippet-detecting-binding-errors
You can use Snoop for this: http://snoopwpf.codeplex.com/
Just use Snoop to point to your application and then you can sort on Binding Errors. All Bindings Errors will be highlighted in RED, and show the property of the control.
Essentially the warning in our case is just a validation, we don't want to mark it as an error just a warning so the user knows. I was hoping to use the same or similar method used for validation. Currently I'm leaning towards implementing IDataErrorInfo. But I'd like to change the style on display and allow saving. Has anyone done anything similar? I don't want 2 separate solutions for validation.
during validation, set some corresponding properties.
eg: IsInWarning and IsInError.
set these properties according to the validation logic in the error handler and then use a datatemplate to style the items with triggers.
something like that?
(sorry no time to mock up an example now...)
WPF has a built-in mechanism for handling validation via IDataErrorInfo.
There is a good CodeProject article describing the process, but it basically comes down to supplying an ErrorTemplate that's used for items in an error state, and telling WPF to validate your objects. If they implement IDataError info, you can have their style change, plus use that to present error messages directly.
I just wasted invested a good chunk of time trying to determine why a specific datagrid among many was showing shrunken rows with no text. After many trial and errors attempts to figure out what made this grid special, I finally found that the class used for the row items was marked private.
That is a perfectly good reason, but I would have prefered to have been able to narrow it down to a binding issue (and if possible a "field is not accessable due to protection level" type message) much sooner then it took to sysmatically disassemble the entire convoluted process it took to get data into and configure that grid. Ideally I shouldn't have had to see the wrong behavoir in the first place, an error should have occured immediately when a column attempted to read from a field that it could not.
All my datagrids inherit from a custom base class in order for some global standards to be applied - if there anything I can do in my CustomDataGrid class to cause an exception to be thrown whenever a columns binding expression fails, such as if the class/property is private or the property name has been mispelled in the binding expression? (This is different from binding validation).
I always keep an eye out on debug output window when dealing with SL/WPF databinding. The framework(s) are actually pretty good at generating messages about databinding problems that include specific details about what fields it failed to bind on or what have you.
This doesn't exactly answer your original question, but it helped me sort through binding issues quite a bit once I realized there was good info being thrown into there.