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.
Related
I am planning to learn XAML. I wanted to know if I should first learn about WPF and then start XAML?
Please advice.
It depends on what your future plans are with XAML/WPF. If you want to get up and running and use it as quick as possible you might consider starting with XAML and WPF at the same time (but note that you can't learn or use WPF just be learning about XAML).
If you plan to work with XAML/WPF for a long time and you will have a lot of WPF projects ahead you probably should consider starting with "pure" WPF.
I belong to the latter camp and it helped me a lot to first get to know the WPF object model, rendering and layout system and then start with XAML, styles, templates etc. For me it made thinks easier to understand (and there is a lot to understand). I understood that XAML is just another way to represent/serialize a .NET object graph that is built as a layer on top.
This is also the way Charles Petzold's book is structured and I think it is the perfect book to start with when you want to get to know WPF really well.
Its not a good question but WPF applications are is built on XAML. I started learning from WPFTUTORIAL
You will find that you will are likely to learn both at the same time. That said, XAML is a designed to be a mark-up language and is used for several technologies, e.g. WPF and WCF et. al.
As #bitbonk mentions, several books on the subject first give you an introduction to WPF (Dependency Objects, Visual Tree and Logical Tree, Controls, etc) before showing any XAML markup.
Whatever you do make sure that your first 2 or 3 applications are throw away apps (not production code). I have seen way too many developers code themselves into a hole when learning to code with WPF. I would recommend studying the MVVM pattern as well. This is critical to building stable WPF applications.
Here are some blog posts I have written that may be of some assistance.
http://tsells.wordpress.com/category/mvvm/
A while ago, I posted a question regarding switching between a Blend-authored GUI and a Visual Studio-authored one. I got it to work okay by adding my Blend project to my VS2008 project and then changing the Startup Application and recompiling. This would result in two applications that had completely different GUIs, yet used the exact same ViewModel and Model code. I was pretty happy with that.
Now that I've learned about the Laurent Bugnion's MVVM Light Toolkit, I would really like to leverage his efforts to make this process of supporting multiple GUIs for the same backend code possible. The question is, does the toolkit facilate this, or am I stuck doing it my previous way?
I've watched his video from MIX10 and have read some of the articles about it online. However, I've yet to see something that indicates that there is a clean way to allow a user to either dynamically switch GUIs on the fly by loading a different DLL. There are MVVM templates for VS2008 and Blend 3, but am I supposed to create both types of projects for my application and then reference specific files from my VS2008 solution?
UPDATE
I re-read some information on Laurent's site, and seemed to have forgotten that the whole point of the template was to allow the same solution to be opened in VS2008 and Blend. So anyhow, with this new perspective it looks like the templates are actually intended to use a single GUI, most likely designed entirely in Blend (with the convenience of debugging through VS2008), and then be able to use two different ViewModels -- one for design-time, and one for runtime.
So it seems to me like the answer to my question is that I want to use a combination of my previous solution, along with the MVVM Light Toolkit. The former will allow me to make multiple, distinct GUIs around my core code, while the latter will make designing fancy GUIs in Blend easier with the usage of a design-time ViewModel. Can anyone comment on this?
I checked your previous question and this one, and I had never really heard about switching projects to work in Blend and in Studio, and end up with two different UIs. I think this was not the intent of MSFT when they built Blend. Instead, the possibility to open the exact same project and code files in both IDEs (and all the discussions I had with the various teams at MSFT) hints that the intent was in fact to have one application only which can be edited in both environments.
I think that in the end, the goal is to have a variety of tools that you can use to edit your UI - XAML, Visual Studio designer, Blend. Depending on your role in the project (developer, designer, integrator) and depending on your ability with the tools, you can choose one or the other.
This doesn't mean that we never switch templates! Depending on the kind of application (for example between a SL4 desktop application or a WinPhone7 application), we use the same ViewModel (and below) code, but slap a different UI altogether on the files. I demoed how to do that in this video:
http://channel9.msdn.com/posts/kreekman/TechDays-2010-Understanding-the-Model-View-ViewModel-pattern/
This is the same talk I gave at MIX but extended by 15 minutes where I show how to reuse the ViewModel and model files, but use a completely different UI for WinPhone7.
Another application is switching templates when a window is resized (used very often in WPF, but also applicable to Silverlight) in order to show less details or a different layout for different screen sizes.
I hope that this reply doesn't confuse you :) and in fact, I'd love to hear your comments on that before we continue the discussion.
Cheers,
Laurent
I think MEFedMVVM would be a good candidate for this. It is simple and you can combine it with other frameworks.
Would it be practical to create WPF applications without ever touching Visual Studio (or any other IDEs)? As in, coding and compiling completely within Vim and the command-line? What resources would you recommend for someone trying to do so?
It would be possible, since basically WPF is based on XAML - a variant of XML - and C# or VB.NET or another .NET language as its backend language.
The question really is whether that's practical and if it makes sense - I highly doubt it. WPF is all about visual design, e.g. totally without a visual designer (either the built-in one in Visual Studio, preferably the 2010 version; or some other visual designer), it seems a bit silly to want to program WPF....
As for resources - well, a least a text editor is a must, then definitely a few good books on WPF, and you could leverage the C# or VB.NET compiler that comes with the .NET framework.
I have found myself writing XAML in Notepad on a number of occasions where I needed to create a quick UI but couldn't load an IDE. It is really quite trivial, and almost - but not quite - as fast as using an IDE. The main advantages of an IDE such as Blend or VS.NET are in quickly getting things like colors and animations to be "just right."
Another occasion when I frequently write XAML or C# in a text editor is here on Stack Overflow. I only fire up Visual Studio when I need to test something out.
My main recommendations for creating WPF applications without an IDE are:
First you should make proper use of WPF's layout system, using appropriate panels and "Auto" sizing wherever possible. For example, if you want a stack of buttons with some space between them, create a <StackPanel>, and on each button add Margin="4" or whatever. This is good design anyway. Most beginning WPF programmers treat it like WinForms with no layout capability, which is a shame. WPF has a very powerful layout engine and it should be used. If it is, there will never be any need for graph paper or measurements. In addition, your UI will automatically adjust its layout if you change font sizes or objects are larger than expected.
Second you should use msbuild for your project unless it is ultra-simple. msbuild is installed along with NET Framework so it is always available. The file format is very easy to edit with a text editor, and it is much better than a batch file with the appropriate "csc" command because it allows you to use code-behind and is less error-prone when adding new source files.
Third keep a PowerShell command line window open separate from your editor, with a command that runs "msbuild" and then executes your application. To run your app, then just Alt-Tab to this window and hit uparrow, Enter. Some text editors have the ability to execute user-defined commands directly from within the editor and see the output, in which case this second window is not necessary.
Fourth keep a copy of cordbg or mdbg handy. Although an IDE is the ideal place to do your debugging, any debugger is better than none at all. You will find your problems much faster if you stop at breakpoints and examine variables than if you just keep editing code and re-running.
Fifth, use "ColorPad" or a similar application to select your colors for use. Just guessing and entering your best guess in hexadecimal just doesn't work very well.
For resources, I recommend you get the book "WPF Unleashed" and work through the examples. I would also read a lot of other people's XAML, such as can be found on CodePlex.
Possible, Yes. Practical No.
For production work, I would consider Microsoft Expression Blend 3. Then copy the XAML and paste it into the editor of your choice and compile from the command line.
You could download KAXAML . It's a free, lightweight editor. I found it good for learning about XAML and seeing how minor changes and tweaks can impact on an overall design.
XAML is plain old text so find a free editor (KAXAML), use it, and if you must, paste into your editor.
If you really want to go down this route, I'd recommend getting some graph (squared) paper and a sharp pencil.
Draw out your designs on that, read off the positions and type them into your editor of choice.
One benefit of this is that you're going to have a paper prototype to show people ;)
As James Keesey points out in his comment on marc_s's answer, your edit-compile-test cycle is going to be painful.
It's definitely possible. I'd say it's not practical, though.
To be honest, I do professional WPF development and I do it with the visual designer closed. I'm much more comfortable editing the XAML by hand, just like I write HTML. However, the benefits of an IDE go far beyond the visual designer. There's IntelliSense, debugging and a whole host of other invaluable features.
Really, I must question your motives. What are you trying to gain? Visual Studio Express editions fully support WPF development, so it can't, or shouldn't, be a cost issue.
The newest version (3.0) now supports the wpf template.
Just download it from: https://dotnet.microsoft.com/
Just type in console:
dotnet new wpf -o wpfHello
cd wpfHello
code .
Greetings :-)
I've been doing WPF applications with the MVVM pattern using Visual Studio, coding C# and XAML mostly by hand.
Now I've gotten up to speed with Expression Blend so that I can click together WPF applications quickly just using the GUI, which is very nice, much more control of the layout than fiddling around with all the XAML elements 80% of your time.
But it seems that my applications in Expression Blend are simpler and necessarily coupled, using events that are handled in the code behind, etc.
I find it hard to imagine how I would go from this simpler approach of Expression Blend to a decoupled MVVM application with Views, ViewModels, routed events and commands, etc. other than to just take my whole project into Visual Studio and rearrange it to the point that I couldn't really edit it visually anymore in Blend, but would be back to using Blend to create little pieces of XAML that I paste into Visual Studio.
For those of you who are working with more complex applications with Expression Blend, what are your strategies for keeping your projects decoupled in an MVVM way, yet at the same time structured "in the Expression Blend way" (where you can still see and edit whole parts of your application in a way that makes sense visually) so that you can continue to edit them in the Blend GUI as they scale?
I've been using Blend first and foremost as a rapid-prototyping tool. For this purpose, I really like it. In particular, I find it very helpful when I'm not sure how to set things up to get the layout/behavior that I want.
I rarely edit my main project files directly in Blend. I find it creates markup that is unnecessarily complex or verbose. Also, as I become more familiar with WPF/XAML, I find myself using Blend less and less.
I have been using Blend for the UI of my projects since version 1. Being that my goal is to fully integrate the designer to the project, I have plowed through whatever gets in the way of this goal. While not being aware of MVVM for some time now, I naturally arrived at the same conclusion, and have been making ViewModels without knowing there was a pattern for them. Now with the help of others that are working towards MVVM, it's getting better all the time. I have now developed 3 applications with rich UI and functionality where all the UI was done in Blend.
Read Josh Smith's MSDN article, look at Jason Dolinger's work, and Karl Shifflett's work to mention just a few.
Look closely at using ICommand, INotifyPropertyChanged, the ObservableCollections.
Also, look for how you can manipulate controls from your ViewModel. As an example, there is ICollectionView. Assume that you have a list of animals, and you have a set of types that you want to filter them by (birds, mammals, etc.)
By using ICommand and ICollectionView, you could expose enough control where a designer could construct a listbox to show the animals, and a menu to show the filter list. There is enough functionality in ICollectionView to know what the current selection is, and if you had ICommand-based commands for "SortByBird", "SortByMammal", etc then when the designer made the menu, it (assuming the window's context was your ViewModel for this window) would supply the designer with the proper options to bind to.
I am currently working with another team at my company explaining how my projects have been set up, and they are responding positively to the new role of the designer using Blend.
I have not been able to successfully use Blend end to end for that.
I find in the general case, it's faster to edit xaml by hand in VS (exception would include anything with non-standard brushes for example). Blend is very click-happy, and it's not really fast to top it off.
Another area where Blend is really useful is creating styles/templates from existing controls.
Other than that, I'm not sold yet. Its capabilities drop when using code-instantiated datacontexts so it's no help there, and it tends to generate useless markup, static sizes and such, which I really don't like.
Blend is great for giving you an idea about how things can be done, but the xaml it makes is terrible and tightly coupled. As you learn the xaml side of things better you'll find it's much faster to just write the xaml than use Blend. Until you get to that point you can make your changes in Blend but then you should refactor the xaml it creates to make it less tightly coupled and take out the extraneous UI elements.
I'm a little late to this party, but hope that someone can still respond. I've yet to find a search result that outlines the process for drawing a line between the designer and programmer. The first part of it is MVVM so there isn't any coupling between the GUI and the underlying "business logic", and I'm working hard on learning that right now. The other part that I haven't seen anyone write about is, how do you actually go about designing a project in Blend so that the developer can basically give you a GUI DLL of sorts, and then your application's GUI magically changes?
Here's what I'm looking for -- the developer writes his code as usual, and also writes a very basic GUI that proves everything works as expected. Meanwhile, the designer is creating his cool little GUI with all of the usability features people have come to expect. Now, the developer can run his application with his GUI, but then can also switch to the designer's GUI on the fly.
I guess if it can't be done on the fly, does that mean in the ideal case that the developer would have his VS solution include the XAML from the Blend solution? Then in App.xaml just reference a different start file?
Do you expect your WPF developers to know expression blend?
Any good resources for learning more about Blend?
[UPDATE] Does knowing blend make you more productive?
I found Blend a great way to ease into XAML. Many of the common things you want to do are easy in Blend, especially databinding. Databinding has no intellisense and I found doing things in Blend a great way of discovering how do write the databinding syntax.
I now find myself mostly editing raw XAML buy hand.
The areas where blend is really handy:
Customizing templates.
Animation
Breaking the UI down into user controls
As a WPF developer I surely see the benifit of knowing Expression Blend for many of my previous projects. This help me to jump start on creating Usercontrols and Custom controls very effectively. And if we do in the conventional way of writing XAML from the scratch, it is gonna take a very long time of your development.
And also for creating DataTemplate,ControlTemplate,Styles and ItemsPanelTemplate - it is just a click away in Expression blend.
So I highly recommend Expression blend for a WPF programmer
I typically work in both blend and Visual Studio (2005) side by side when doing WPF development. (Although, granted, I typically do both design and c# coding).
The benefits of using Blend is that certain tasks are extremely fast there - things like picking colors/brushes, creating animations and layout fixes such as tweaking margins/paddings.
Another usage is to instantly see how your hand written XAML will look like without actually starting the app.
Blend has a bad habit of producing some weird XAML so I always have to clean it up in the VS text editor afterwards. I still find it to be a net win to use blend though.
So, to answer your question: Is Blend required? no, not really. But it will make your life easier for certain tasks and thus make you more productive.
Things like animation and gradient color definitions can really only be done effectively in Blend. Blend is also often extremely useful for generating some non-trivial custom visual elements, just so that you can view the generated Xaml and import a CLEANER version into your production code. Unfortunately, the point-and-click nature of Blend disguises the fact that huge volumes of very messy Xaml is being generated under the hood, and you'll want to REFACTOR that Xaml before using it in your production source. Fortunately, learning Blend is not that hard. The best tutorial I ever found was called the "Fabrikam" tutorial. There may be updated versions available, but one version of that tutorial is still available at the link below.
http://blogs.msdn.com/expression/articles/516589.aspx
Realistically, very few dev. shops have access to qualified "interactive designers" (its not somethiing a company can just re-task one of its junior Mar-Com people to perform), which means, at most places, developers will need to learn some amount of Blend if marketing wants to add the kind of fancy visuals that provide alot of the justification for using WPF in the first place.
As a developer, after working intensively with WPF for several months, you will find yourself becoming totally comfortable editing Xaml directly and, unlike with Windows Forms, you'll rarely rely on features in the VStudio designer. Not only is direct editing MUCH faster than scrolling through property lists, but VStudio does not have point-and-click support for many of the features you will use in production WPF applications (they just got around to adding an "event" tab in SP#1). Blend has more support for many of these items (it can generate a DataTemplate, for instance), but I usually only jump into Blend to create a quick animation or other visual effect, cut and paste a carefully-refactored version of the markup into my "official" VStudio project source, and move on.
I think at least the designers should start using the Expression Suite.
The developers should be somewhat familiar with the tools but just enough to enable them to communicate better with the designers.
Since there are not so many good WPF tools, knowing Blend is a pretty useful skill. However I wouldn't consider it as requirement. The whole idea of WPF is to distribute work between coders and designers. IMO developer is not required to know Blend throughout, but basic skills are required to understand designer's needs.
Video training for expression blend:
Total Training Expression Blend
http://expression.microsoft.com/en-us/cc136536.aspx
http://windowsclient.net/learn/videos_wpf.aspx
I (as a developer, not designer, soo not designer) tried to start learning WPF through Blend. While I could get stuff working, looking back at what I produced makes me shiver.
Now that I know my way around WPF pretty good, I still use Blend and Design every now and then, but my work is based in XAML (not designer view in VS, mind you, but XAML). In other words,
I know how to clean it up now.
I'm still wondering how I can get my Adobe-Flash, -Photoshop, -Illustrator design guru to work with me in WPF.
It fully depends on what you want to do. To answer your second question, would you really want to try editing an animation storyboard outside of Blend? If you're working with the actual Visuals of the application, Blend is best suited for this. If you want to hack around with databinding, validation and other things where you must swap back and forth with code. Obviously its more sense to work on the XAML in Visual Studio.
Lynda.com has some cool expression blend training available online...
Getting Started with Expression Blend by Lee Brimelow
Developers don't need to know Expression at all.
What you do need to know is XAML and not hide behind some tool, which would be the worst thing you could do as a WPF developer. Your tool of choice is yours to decide on. I used to use the XML editor in Visual Studio.
The only persons who need to know Blend are the ones in charge of the visual aspect of your WPF application. They have to be able to understand how to skin your application with templates, but other than that, they can keep to Blend exclusively.
In general, I think it's more important to for developers to understand XAML, as Blend is just a view on top of it. XAMLPad may be more useful for learning XAML in the first instance.
More specifically to this question though, I think if developers are working alongside designers using Blend, it could be very useful to know at least the basics. As well as allowing better communication (as mentioned by #kokos), it will let the developer perform minor edits (such as alignment etc.) in the same environment, and also understand the limitations and boundaries of the tool with respect to the code generation.
Historically, designer tools have had a few quirks that developers have had to work around, such as re-coding HTML in FrontPage, or generating font tags instead of using styles or classes. I'm sure Blend wouldn't do such things, but it might generate XAML that the developer would prefer to restructure or slim down, so knowing which features generate which styles of code could be very hand for the developer.
Would you require your HTML developers to use DreamWeaver?
All good WPF coders should know XAML by hand and only use tools like Blend for quick mockups, for doing animations or tweening, or for doing complicated gradients, etc.
Coding XAML by hand is a requirement for good WPF developers - Blend is a tool, not a substitute for knowing XAML.
Brennon Williams new book should also be good!!!
(source: pearsoned-ema.com)