I enjoy developing for the web, HTML/CSS/JavaScript are easy to debug and see what is going on with tools built into modern browsers such as Chrome/Firefox and simple things such as view-source
But with WPF, I'm constantly getting into moments where I think something should happen and it just doesn't. I eat up a lot of time in frustration trying to figure out why a damn button is a certain color or text isn't showing up, etc, etc.
How do you make WPF bearable? Am I missing out on any tools? I know I can prototype in tools such as kaxaml but it doesn't always translate into the real thing.
I want an "Inspect element" when doing WPF!
Snoop is the closest thing to Firebug you're likely to get. One thing I can't stress enough though is to watch the Output window while the app is running - it will tell you when styles/brushes/whatever fail to load.
Also, if you're working in a big project and are having issues with a control or style, pull it out to a separate dummy solution and see if the problem persists. XAML isn't as bad as CSS when it comes to weird inheritance issues, but it can really help you see what's going on.
I want an "Inspect element" when doing WPF!
I would recommend trying Mole 2010. It includes a visual inspector for WPF applications.
Related
Recently I started a project in WinForms. I'm coming from WPF background and I find some things new to me. For example every time I want to change a property of WinForms control I have to scroll up and down to find it.
It drives me mad. I would rather type first few letters of looked up property and edit it in a couple of seconds. Is there a way to speed up this annoying process?
There is no easy way to filter properties of control. I know how you feel, as I switch between WPF and WinForms from project to project. But you can always either Categorize them or sort them alphabetically... I am sure you'll get used to it eventually, but you have to understand though, Windows Forms are not as "innovative" as WPF is. Therefore you'll see some things are rather more "traditional" than WPF in WinForms! Sorry mate :)
There is a VS Extension called RapidDesign. It is a payed project but I think it's worth the price. It does exactly what you need and even more. (Note!!! I am not connected in anyway with the author/company that develops this product)
https://visualstudiogallery.msdn.microsoft.com/c820e3a0-add2-4a43-943c-029e296ab00d
You can download the extension directly from VisualStudio galery or you can install it from inside VS by going to Tools->Extensions And Updates...->Online->and search for RapidDesign
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.
I bet you guys know Google Chrome browser, yeah it comes from Chromium open-source projects, added some Google specific features.
I found the multi-tab GUI is quite attractive, especially the "drag-and-drop" feature for tabs and windows:
to "pull a tab" out to form a separate window, or
vice versa, to join a tab into a windows (that has a collection of tabs).
This would be quite helpful for designing some multi-process applications to achieve the stability, and a cool user experience, but ... how?
is it possible to do this in WPF?
or even one step more, is it possible to do this in MVVM?
Yeah, technically, everything is possible, but I can't see an easy pattern to do this
for WPF, how to handle such specific "crossing window" mouse interaction?
for MVVM, hmmm, will this be too challenging for MVVM?
cheers
maybe you should have a look at these libs/frameworks:
http://fabtab.codeplex.com/
http://avalondock.codeplex.com/
http://fluidkit.codeplex.com/
Its definitely possible. I've recreated the chrome tab look in the past with MVVM, complete with drag and drop, and I know another guy who created a tabbed application that lets you "pull away" tabs into a new window of its own. I believe it was all one application with multiple windows, so all open windows were part of the same application even if they show up separately in the task bar.
I'm not sure if I have his source code or not, I'd have to go digging for it.
i've been learning wpf for about a week now..
and i have a basic question:
From a business view and development view (out of your experience).. what can and what cant be done with wpf(capabilities) ..
please try to be illustrative..
examples of undesired answers:
"Fully functioning stand alone applications with alot of animation and Glittering images"
A second question:
if i build a XBAP UI for my application, can i make the UI "not show" in a browser!
if u r going to answer from tutorials/websites/books.. please dont copy paste them directly, try to write it in your own words...
You can host anything built to the Win32 GDI/USER API (WinForms, ActiveX controls) inside a WPF application, so even if you hit some limitation with an app that is mostly WPF, you can always host some old controls inside it.
And since 3.5 SP1 you can even host animated DirectX graphics pretty seamlessly as well (although WPF's 3D support provides its own much simpler ways of achieving the most commonly done things).
As for comparison, the major advantage of WPF over WinForms is the way it keeps closely to its own component-based model, so a very large proportion of controls are able to act as containers for other controls. Want to put a combo box in a menu item? Not sure why you would, but you can. More usefully, you can put a button in a list box (or tree view). These kinds of thing are not possible unless you implement every standard control from the ground up (which is what WPF does).
The disadvantages are probably temporary: it can be a little unstable on some machines (the rendering code seems vunerable to display driver incompatibility) but this gets better with each service pack. Also the text rendering has been heavily criticised - it goes a bit further with ClearType anti-aliasing than Windows normally does, so some people complain that it looks blurry.
(The reason these are likely to be temporary issues is that Microsoft's Visual Studio 2010 is adopting WPF. So they are now "eating their own dogfood".)
You can pretty much do anything in WPF that you'd need from a GUI app. But that's not the real benefit, IMHO.
One of the real benefits of WPF is development speed and simplicity, once you get past the learning curve (and there is a learning curve!)
The other major benefit, and probably the biggest one, is that it allows designers to work on the presentation, do lots of interactive things, all using a designer-friendly (friendlier, anyway) tool and not having to submit requests to the coders. Just by changing the .xaml, a designer can make an application look almost completely different, and add all kinds of behaviors (panels disappearing, expanding, all kinds of neat stuff). Without changing a line of code.
You can in theory do anything in WPF what you want. Compare it with a WinForms application. Is there anything that you can't build with that? Not really. The same goes for WPF. It's just that WPF is better suited for some things, like animations, video, graphics, etcetera. As it is xaml based, it is also better suited for databinding against XML for example.
See also this related question.
As for your second question, I'm not sure what you mean by that. Do you mean if you can show websites using WPF? Yes of course, just like WinForms.
Oh, in WPF some things are still not implemented. DataGridViews as popular example are only in the codeplex preview. YOu have alot of things like theExpander which work in a differnet way, and you can have a lot of problems with autosized content.
I have a binding in Silverlight that is causing my application to exit. An unhandled exception is not throw; I just get a white screen.
I am not seeing anything from the binding engine in the output window.
Does anyone have any ideas for debugging this issue?
I suggest you use Karl Shiflett's Glimpse for Silverlight for that.
Also, I just "heard" Laurent Bugnion on twitter recommend using a mock Converter on a binding to figure out why it's failing. That's a good idea in case you're unsure as to what values are being fed to the binding.
Dave, dont get too excited about the XAML debugging in SL5. I have been building projects for a few weeks now in SL5 and all I can say is that the XAML debugger will break after very little use and all you will get back is the ridiculous error message saying that the PDB's cant be found. I have reset my VS2010 setting numerous times and still the debugger remains crippled. I have spend days if not weeks trying to get to the bottom of the cause and as usual there are no support documents or help sites for this issue. Debugging Silverlight databindings is a black box scenario and a huge weakness in this technology. There is no way of knowing what the XAML parser is doing or not doing as the case may be. I have just had to scrap a project because of a total failure of the bindings in the View. The VM is preforming correctly by all bindings on the view fail. People will tell you that the output window in VS2010 will indicate the binding errors. My experience is that you can have total failure of bindings and NO errors will be shown in the output window. If you get into this scenario there is simply no solution that I am aware of and even the bug ridden XAML debugger wont be able to help you.