Almost every example of MVVM I found is coded in C#, are there any examples/tutorials coded in VB.Net? I'm having a hard time translating C# to VB.Net since I haven't really used C# in any meaningful way...
Also, does a MVVM Template/Toolkit for VB.Net exist yet?
You might want to look at the work of Karl Shifflett (program manager on the Cider team at Microsoft). He's one of the main forces in MVVM, and he deals pretty much exclusively in VB.NET, so you'll have plenty of samples to learn from. As an added bonus, he's written a framework called Ocean that should help you get started.
You can find more details on his blog here.
You can download the sample app made by Josh Smith in the MSDN article "WPF Apps With The Model-View-ViewModel Design Pattern" in VB.net form
In general, all code in MSDN mag gets translated to VB.net.
I'm in the process of porting the (MVVM Light Toolkit) C# project templates and code snippets to VB.NET.
I've finished the Silverlight 3 template, now working on the others.
The VB Silverlight 3 template for Visual Studio 2010 is here.
The VB WPF 3.5sp1 template for Visual Studio 2010 is here.
Prism now has samples in VB which you can download here.
This article gives an overview - Prism allows you to develop in either WPF or Silverlight (or do linked projects which provide UIs in both WPF and Silverlight with some code) - the article mentions Silverlight but you can ignore that and still get an overview of Prism/CAG.
On the other hand, there are C# to VB translators out there - have you tried them? I made the switch from VB to C# a while back when I found that all of the sample code for the areas I was interested in were in C#. I'm glad I switched. From your PoV, it probably looks harder to read but once you're into it, it's so much easier because there's so much less excess code to clutter up the screen.
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/
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 am looking at using WPF for the GUI side of an upcoming project.
I know I have a huge decision to make on WPF vs. Win forms, but before I can make that decision I want to have a play around with a few simple WPF programs.
I have read a few posts online that say Visual Studio (2008 at the time of the post) lacked somewhat in editing the XAML and they recommended using MS Expression?
Questions are:-
I have VS2010, Has this fixed the lacklustre XAML editing present in VS2008?
Which product in Expression studio is used instead to edit the XAML?
Is the idea that you build the code side of the WPF in VS and Build up the XAML in Expression the copy the generated XAML into VS?
Any suggestions/tips on combining Expression and VS2010 would be appreciated.
Kind Regards
Ash
VS2010 has a much better enviroment for supporting XAML compared to VS2008 (in VS2008 it really was not the greatest experience) - so it would be possible to play around with some basic projects straight in VS2010...
Expression Blend really shows it power when you get into animations and transitions etc (Expression Blend to me would be the starting space in the Expression suite once you had covered the basics in VS2010).
The approach I would take is to get basic exposure in a tool/ide you are used to like VS2010, and then go through some of the Blend examples/tutorials that are available off the Expression Website to then take it to the next level.
The things that got me sold on WPF/Silverlight were databinding, separation of concerns using the MVVM pattern and commanding... it just seemed easier than what I was achieving in the winforms arena and cleaner... but it took a while before I was sold on it just because I was used to the winforms way of things and was trying to do WPF but with a Winforms approach.
For basic projects you could build the code and XAML all directly in VS2010. In fact for someone learning XAML for the first time who comes from a code centric perspective, coding XAML directly in VS2010 might be beneficial so that you get used to the basic syntax before you work in a tool like Expression Blend where that can be hidden from the developer.
use VS2010, it has much better intellisense support for XAML (and better support for large solutions >50 projects).
also you dont copy over files between Expression blend and VS2010, both open the same solution work on the same solution (Blend now has support for source contorl as well), you can flip to show the C# in Blend and vice versa in VS2010
I am working on Silverlight 3.0 and currently using code-behind in my Views. I would like to implement the MV(VM) pattern into my project as the project is growing. I have seen some WPF projects where the code-behind has NO CODE except for the InitializeComponent method, which I believe is the right way to go and just looks clean. Is this possible in Silverlight 3.0, that is, no code-behind?
Can anyone point me to some good Silverlight (3.0) MV(VM) tutorials / articles?
Without using some additional framework, Silverlight 3 does not support what you saw in WPF. Specifically, full Commanding support. Silverlight 4 has included Commanding for Buttons, which is a start.
You can look into other frameworks that provides this feature set, like Prism. This will get you along the right path, but I'm sure there are other options.
You can follow the MVVM pattern for Silverlight 3 applications without using a framework. However, it is much easier to use one of the many MVVM frameworks out there. Here are a few good ones:
MVVM Light
MEF
Simple MVVM
I'd recommend not using Prism as it is more complicated than it needs to be.
Other options include things like MVVM Light, which is lighter weight alternative to Prism for things like handling events and commands, however Prism does have a lot of functionality (and the Prism 4 talk has that sounding like a good option when it gets released).
One good community site to check out is the Composite Development Patterns Community, which was newly started but has an excellent goal of collecting articles and other help for working with development patterns like MVVM.
Lastly, John Papa gives a great overview of MVVM, limited to links so head to Google and look up "John Papa MVVM". :)
One thing to consider though, resources for SL3 aren't going to be as valuable as those for SL4, which opens up additional options for framework based commanding (ICommand that greglev mentioned), although it isn't still the full command support from WPF.
Jesse Liberty has a good primer on MVVM also using Behaviors for wiring events.
Silverlight and MV(VM) Pattern - No Code-Behind - Is this possible?
I've been very happily using the Model-View-ViewModel (MVVM) pattern in WPF and Silverlight apps in combination with C#. Declarative XAML markup and data binding are invaluable - I just can't live without them. But, this talk by Harry Pierson on dynamic languages got me excited about learning a dynamic language, and I'd like to try one out in a new project. I've been enjoying reading IronPython In Action, and it does contain a few WPF examples - but only with imperative-style code.
What are your thoughts on using IronPython or IronRuby at the ViewModel and Model layers in MVVM apps (compared to C#)? Which features of make them attractive (or unattractive)? I'm interested in fundamental advantages/limitations (e.g. AOP, duck typing, monkey patching, static type limitations, etc) and practical ones alike (e.g. performance, no current IronPython Studio for v2, etc). Will any limitations improve with C# 4.0?
Thanks,
David
Shay is right, but only for Silverlight and I've not used Silverlight and IronRuby. You can bind and use commands with pure IronRuby and WPF. I'm assuming this also applies to IronPython as they both use ICustomTypeDescriptor. there is a caveat, you'll need a DLR build more recent than IronRuby 0.9 for events.
To create an IronRuby command, you need to implement events. See this SO question for more Implementing and Interface in IronRuby that includes CLR Events
As for creating an IronRuby object that can participate in binding, the deal is a an attr reader/writer needs to be used for the DLR to see it as a property.
class Bindable
attr :some_property, true
end
I've got a few Gists about it. A Command Example, A simple ViewModel Example with Binding And the XML Builder based xaml library used in the examples. These worked for me.
There are limitations. XamlLoader can't see IronRuby classes from the CLR. This means your views are REALLY dumb (zero code-behind), or they come from a C# dll. It also means that you can't create custom or user controls that have any code behind without going to C#.
While I don't have a fully baked MVVM app in IronRuby/WPF, I think all the pieces are in place and I'm getting there.
I can say that writing WPF with IronRuby is pretty cool, and if you invest a little time metaprogramming your environment, it can be awesome.
However, there are the downsides - data binding doesn't work with IronRuby objects (you must use CLR objects for that - look at my blog post for the workaround), but this should improve on .Net 4.
Pay attention that IronRuby is expected to go RTM only in November.
Having said all that, I do recommend you check it out. You might fall for it like I have :)
Shay.
I've blogged about my experiences trying out IronPython and MVVM with WPF here. It was surprisingly easy to get going.