I am wiring up a binding in code (NOT in XAML).
Is there any way of determining whether the binding path is valid? The obvious candidate is IsDataBound property, but this is always true even if the path is wrong.
Currently I am fudging it by supplying a fallback value and testing for that, but is there a better way?
If you don't mind upgrading your project to Silverlight 5, check out the Silverlight 5 RC. With SL5 debugging databinding has become a breeze since it enables you to set breakpoints inside your XAML code where the binding happens.
Check out this article for a full overview how this works.
The Output-window of Visual Studio is a good place to start, for a more indepth guide on debugging bindings see this MSDN article.
I guess you could use a ValueConverter, which you can add pretty easily in code to your binding and will let you evaluate what is going on between the source and target properties.
Related
Love Angular, and love MV-* in general. However, on any framework I've ever used, debugging databindings is just a pain -- you put the wrong binding expression in your view, and you just don't get data. It's a big Q/A issue. for data-entry intensive applications.
Are there any resources out there for detecting/debugging databinding problems in angular? (I'm particularly interested in detecting cases where the binding experession in the view has a typo, so that the target your binding to simply doesn't exist)
Angular-Team develops Google-Chrome extension - AngularJS Battarang
It can extract scope, available on curent element and shows its values.
I'm new to the Windows world, and I think I'm getting lost in the weeds on a problem. I'd love some advice from people with experience with C++/CLI and WPF and XAML.
I have some win32 code, and I need to run a WPF GUI. I found this MS walkthrough sample, which uses C++/CLI. I adapted it to my purposes, and it works great.
Next, I wanted to rip out the programmatic WPF stuff and use XAML instead. This is so I can hand off the XAML to a designer person and take myself out of the UI design loop, where I most assuredly don't belong. After reading the "WPF Interoperation Projects" section of WPF and Win32 Interoperation on MSDN, I decided to go with the XamlReader::Load option and load uncompiled XAML at runtime. My XAML markup is a Canvas UIElement which I programmatically add as a child of my root Grid C++/CLI element. This works great.
Now I want to add event handler to controls in the XAML. This is where I have started to run into trouble. I'm sure that my general ignorance of the Windows world is 95% of what's killing me here.
I started with Rob Relyea's page outlining the various XAML-and-event-handler options.
I decided to try compiling the XAML as a C# DLL. It's basically the same XAML as what I used in the runtime Load case. I instantiate the object and programmatically add as it as a child, just like before. But ... I get nothing but a black window. No exceptions get thrown either. I'm baffled.
My question is, am I even headed down the right path? The page on XAML-and-event-handlers says you can use event handlers defined in uncompiled XAML in .Net Framework 4. Should I bite the bullet and just go to VS 2010 (I'm presently on VS 2008) so I can use .Net Framework 4 and just stick with uncompiled XAML? Are there any gotchas with doing things that way?
Or, if you do think the compiled C# DLL is a reasonable path, do you have any ideas on how I can debug the problems I'm having?
Or, is there a better and completely different approach?
Thanks in advance for your advice.
Polly
I think the right answer for this depends on some issues that only you can decide, but I'll start with the assumption that your C++ code base is big and complex enough that it is worth preserving.
Beyond that the next decision point is do you have UI (perhaps GDI) code in the C++ your preserving or only non-UI code. If you are attempting to preserve only non-UI code then I would consider pushing more UI responsibilty into C#. Perhaps you go so far as to build your views, event handlers, and maybe even view models in C#. This will enable you to take better advantage of the VS tooling.
If you've got extensive UI code in C++ to preserve then your current path makes a more sense. I don't think it will be impossible, but you'll have quite a challenge ahead of you. The key example here is Visual Studio 2010. It is the premiere example of a mixed application and has GDI and WPF side by side unlike any other app I've ever seen or heard of. There is a series of blog posts that I found pretty interesting that describe some aspects of what the Visual Studio team did to achieve this integration at The Visual Studio Blog.
I also came across this video Henry Sowizral on Refacing C++ with WPF in Expression Design that I have not seen myself, but discusses putting a WPF UI on top of an existing MFC C++ app.
Good luck.
I don't have any specific advice on the first part of your question other than to say that putting more responsibility in C# would allow you to build a small stub app if necessary which could go a long way toward diagnosing problems.
Thanks to everyone for the responses. On the matter of getting stuck on the C# DLL, I found this C++/CLI sample: http://msdn.microsoft.com/en-us/library/aa970266.aspx. Using that, I found my error, and was able to load the WPF without problems.
However, the whole motivation for loading the C# DLL was that I had understood that that was the way to attach event handlers programmatically. Following AresAvatar's suggestion, I found that I could use FindName to attach the handlers -- both within the C# DLL, but it also worked with my original loose-XAML approach. So, I didn't need the C# DLL after all!
It's all working nicely now. Again, thanks for all of your help and suggestions.
Whenever I am doing XAML, I tend to run into problems with databinding. It is often small issues, such as misspelling a property name.
My problem is, that I don't seem to receive any errors or warnings when I am trying to bind to a property that does not exist. It would be nice to get a warning, either at compile or runtime, about my errors.
Is it possible to get a warning about wrong databinding expressions ? What do you do to troubleshoot when your data does not appear as expected ?
WPF will write warnings about problems in data binding to the Visual Studio "Output" window
This blog post, How can I debug WPF bindings? helped me learn why my Binding was failing.
I've accepted the other answer to this question because it is technically correct, but I wanted to include the link above in this question, for future reference.
As far as I know, XAML is only used in WPF and Silverlight, isn't it?
Thanks.
No, it is also used in Windows Workflow Foundation:
Using Workflow Markup
XAML is also the basis for XPS.
It is also used in Office 2007+ *x formats
You can use it for whatever you like (beginning with .NET 4.0 if I'm not mistaken, didn't try it in 3.5).
However, if you do so, please also use the other good things .NET has to offer, such as "INotifyPropertyChanged" and dependency properties. Otherwise whatever you create will be a less - than - optimal solution.
There is a huge mistake I often see people make when they say, "XAML is UI markup." It's not. You can have XAML with no UI whatsoever. XAML is, in essence, an XML object graph. It is markup for creating classes. It provides the parser with instructions on how to generate instances of types and set properties on those types. This is extremely useful for creating UI in WPF and Silverlight but can also extend to sample data, view models, and other constructs. As mentioned here, it is also used in Workflow and other areas.
Based on the sample from http://msdn.microsoft.com/en-us/library/ms771725.aspx
which is for WPF. I wanted same sample for silverlight as my requirements are same. but i get
"AG_E_PARSER_BAD_PROPERTY_VALUE" pointing to
in my XAML (FYI: xmlns:dat="clr-namespace:System.Windows.Data;assembly=System.Windows.Data").
Please help me in achieving the same.
There is not a direct 1-to-1 match between WPF and Silverlight nor the XAML used in those technologies. The error you are getting implies that the XAML is trying to set a property that either doesn't exist or doesn't support the value being applied to it.
To track this down, you'll need to look into the differences between the version of Silverlight you are using and the version of WPF that you are porting from. Just googling or binging gives quite a few links regarding this.