One of the hardest things to overcome, as a developer, is yourself. I've been avoiding this topic for far too long and FINALLY understand it. Thanks again, Tim.
I have taken at least a dozen online courses in the last three years. Some of them were Udemy Courses, Professional Development courses through my job, and some were tutorials from other RU-vid channels. You're videos, channel, and teaching style, in my opinion, are superior to most other free and paid tutorials I have taken. Thank you so much for sharing your knowledge.
This guy is still answering questions posed to a video in 2017... How is that for dedication... Thanks Tim, I am currently applying all that I am picking up here! KUTGW!
In the part of the video where you activate the child user controls the method "ActivateItem()" was replaced by "ActivateItemAsync()" Thank you so much, Mr. Corey, for creating these outstanding instructive videos! Keep up the great work, can't wait to learn more from your future videos!
ActivateItem (at 1:17) is replaced by ActivateItemAsync public async Task LoadPageOneAsync() { await ActivateItemAsync(new FirstChildViewModel()); } You can, but don't have to replace
Super helpful Ivo - thank you! I also took a quick excursion with Tim's Sync and Await video, which helped give context to what you provided: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-2moh18sh5p4.html
Lately, I don't even listen to the radio in my car anymore, I just listen to Tim's tutorials. His explanations are great and he often includes a lot of little "gotcha's" that other instructors forget or don't care to talk about. Thanks Tim!
This is so powerful, especially considering that for buttons, as long as your naming conventions are correct, there's all the wiring that isn't needed. I never realized that this was possible with the Caliburn.Micro package. Thanks for walking through it so completely, Tim!
Great video, learnt a lot. BUT I wish we did not use caliburn, because it is doing some little things behind the scene and we are unaware of them. If we learnt hard core WPF(MVVM) without caliburn we would be much more confident. Or video could have been in two ways with and without claiburn. Just saying... Anyways a great video. Looking forward to more videos for in depth usercontrols, more binding concepts between different kind of UIs. Can do a video on ICommands for buttons
I considered doing a video on home-grown MVVM but decided against it for a couple reasons. First, that is much more complicated to do, thus increasing the barrier to entry (and greatly increasing the time of the video). Second, it is essentially reinventing the wheel. Some really smart people spent a LOT of time making MVVM simple and easy to use. There has to be a balance between learning the foundation and taking steps forward. I think in this case, moving forward is more important than learning how the MVVM tool was built. In the same way, I don't dive into how WinForms are built really. I mention it but we don't bypass the drag and drop designer to manually code every button. It isn't necessary because someone has made our life easier. Thanks for the suggestions on other videos. I'll make sure those are on the list of possible video ideas.
Thanks for a great tutorial! I can definitely see some of the benefits of Caliburn.Micro, but I'm struggling to wrap my head around exactly how I should be using it because I don't even know what problems it's solving for me. It also feels like the official documentation explains what to do, but not so much why I'm doing it. Would it be worthwhile to learn MVVM without a framework - or with a lighter framework - first, and then move on to CM once I have a better grasp of MVVM, or am I better off working with CM until I understand it?
This is absolutely brilliant. I was taught MVVM from scratch and I sometimes found setting up the 'plumbing code' to get it working a bit of a headache. I am always a little dubious of using magic words but I think it will be OK once using Caliburn Micro becomes second nature. Using this a new WPF project can be setup for MVVM in minutes.
I appreciate the fact that you don't talk at a million miles and hour and pause frequently. This puts you miles above a lot of the coding education channels on this platform. This makes it so much easier to follow and I don't have to pause the video all the time to read and absorb what your doing.
As a WPF MVVM noob, this video adds to my confusion regarding WPF and MVVM. Why are you using a third party tool for MVVM? Can't WPF do MVVM out of the box? Isn't MVVM just a way to structure the files? Why do you need to install a third party tool for that? Is this tool free to use? Is it shareware? How do the developers of this third party tool get paid? What happens when the developers get bored and stop updating the tool and Microsoft makes an update which causes Caliburn to fail? Now you're screwed. Now you need to redo all the code to make it work with another framework. I'm skeptical of using a third party tool for these reasons. If you must use a framework, why not use PRISM as it's made by Microsoft and should therefore be the "official" MVVM framework? It seems safer to use than some random third party tool made by some guys in a basement. I don't understand why you're so excited over Caliburn. Are you promoting them? You say you "loooove the buttons in Caliburn Micro" but give no evidence to back up your enthusiasm. As a first video on WPF MVVM you go straight to Caliburn without first doing it "clean" out of the box, so the viewers have no idea how Caliburn makes the code different from the original. Is there less code to write? Is the code different and how? You should definitely do a video explaining how to do MVVM without any framework to demonstrate how Caliburn makes the code different and give concrete examples on how it supposedly makes life easier.
I definitely understand where you are coming from. However, there isn't a "clean" way of doing MVVM. Yes, you can build your own MVVM system but in the end, you will have built Caliburn Micro (or Prism, etc. - basically you would have done what has already been done). I use Caliburn Micro right away because it makes learning MVVM much, much easier. Think of it as learning to drive a car vs. building a car to then learn to drive. As for what happens if the Caliburn Micro team goes away, that is why I chose Caliburn Micro. They have over a decade of work into Caliburn Micro. They have a good system of governance and development and have proven to be reliable. The CM code is also open source, meaning if they decided to go away tomorrow, you could still use CM and you could continue to develop it on your own. Again, it would be like driving a car that one day you might need to maintain. You save all of the initial work, even if you need to continue it later. As far as Prism goes, it is basically the same as CM. It is not a Microsoft product. It came out of the Microsoft Patterns & Practices but it is an open-source project that is maintained by an independent community of developers. It is no more stable than CM in that regard. When you build software in .NET, you have two choices: do everything yourself or use third-party frameworks and packages. If you do it all yourself, you are going to spend a LOT of time building and maintaining systems that others have already done. Yes, you get to say that you built it and you don't really care if you go away but that actually makes your code more fragile than if you used third-party open-source systems. With you there is only one developer to maintain the system (or your team if you have one). With third-party, open-source projects, there are typically multiple individuals working on the code. On the other hand, if a project goes away, you have to pick up the maintenance on that project or swap it out. But if that is too much of a burden, did you really have time to build the system in the first place? I personally choose to carefully select the packages and frameworks I use. I don't just pick things blindly. I use Dapper because it is quick, powerful, and supported by the team that runs Stack Overflow. I use Caliburn Micro (CM) because I have a long history of using it. It has been around since before Silverlight. It has outlasted multiple Windows products including Windows Phone Silverlight, and more. I use Autofac for dependency injection because the have a simple way of doing things. I use XUnit for unit testing because I like how they structure things. Those are the major ones. I spent a lot of time testing before making these choices. I hope that clears things up. Basically, using CM makes MVVM easier to learn. Yes, it is a tricky subject but by doing things this way, you are building on the shoulders of giants (which is what the .NET Framework/Core is all about).
Thank you for explaining how Caliburn works with this nice example. The following is just a rant against Caliburn, not your great presentation, so please don't take it personally. At least regarding understanding MVVM: I think that a framework makes things a lot more difficult to understand since you not only have to understand WPF and the concept of MVVM, but also how the framework actually works. From my point of view: if you're a beginner then you have to implement an extremely simple app (click counter with a dialog confirmation is my go to app) without any framework. Implement that several times and then you can proceed to using whatever framework you like. You have to agree with me here that Caliburn does tons of black magic based on very specific visual component names. It basically goes against the normal flow: you don't have bindings, commands and behaviors which are MVVM's building blocks. You learn Caliburn, not MVVM. If you were to get hired in another company that does WPF and MVVM, but without Caliburn - you'd be totally screwed. Everything you know about Caliburn will be useless without the basics. IMHO, Caliburn is actually detrimental to a beginner. Actually, I consider that it's also detrimental to any project - too many things have to match up to actually get it to work, it's damn fragile and the knowledge you gain is worthless for another project without Caliburn. Again, don't take it personally. This is about Caliburn, not you. I enjoyed your presentation and demo. Keep up the great work!
@@IAmTimCorey Thanks a lot Tim, your comment helped me even more than the video. Maybe you can make a video specificly about Caliburn Micro some day. Cheers!
Great video and explanation as always. Do you have any plans to do a plain vanilla intro to MVVM /WPF? Your teaching style is the best and I know I would get a lot out of such a video. Others would like it also from the comments I am seeing.
Thank you so much for this. Some people may say that you break things down too much but sometimes when you are learning a completely new language etc. (I have only ever used python) it is sometimes very helpful to have these things over-explained so you don't have to spend an hour googling to wrap your head around things. These videos are incredibly useful and are often better than paid tutorials on reputable websites!
1000% agree! As someone who knows nothing more advanced than console programming learned at school, I find myself getting overwhelmed by the tutorials I find on RU-vid because some of them just feel like reminders for experienced programmers rather than for beginners to understand. But this particular tutorial is great for beginners for the reason you mentioned.
You read my mind! I too wondered how much code might have been required for a given scenario. I suspect this would make the argument for using a polished framework. Also I wonder if C# and WPF may have evolved over the years to require fewer add-ons. PS. @IAmTimCory, I'm really enjoying the content and will consider taking some of your courses in future. Cheers!
Yes, that would indeed be very helpful. There are many comments in the video about keeping your code human readable yet it seems Caliburn Micro obfuscates many of the connections between view and viewmodel making it difficult to follow what's happening without knowing all it's documentation by heart. Surely that too would be forgotten 6 months down the road especially if it is no longer maintained as other comments suggest and would probably be true for any other 3rd party framework for doing MVVM. Perhaps .NET just hasn't matured in regards to MVVM since there are so many tools around to make it easier...
It's now 1:01 AM in Australia, and I just watched up to 1:03:41. I really like and appreciate your effort to write clear if condition and dodge the negation in the boolean expression. And I agree! Somehow, dealing with negation can be tricky - it tripped me over so so many times in the past, and yet, it is used by many devs carelessly. Keep up the good work!! Love how you not only explore the framework but also promote clean code.
Great explanation, but there's one thing I couldn't figure out how the CanClearText function works? What makes it work exactly? I understand the idea that the ClearText function is enabled but don't understand how CanClearText is enabled? And I probably missed the explanation regarding the matter that the ClearText function should receive parameters, I didn't understand why this should be done
I am with you, great tutorial but there is no explanation of how the CanClearText and ClearText communicate with each other. This part of the tutorial completely lost me :(
@@MikePL101I've just been watching the video, but am yet to try the code and I too was originally confused by how that function managed to get wired up to the button so I rewound the video back to where Tim starts talking about this function and it sounds like all you have to do is create a function that returns a Boolean, and the name of the function has to match the original button function name, but just needs the word Can appended to the beginning. That's why it's called CanClearText. It wouldn't work if was called by any other name. It must be a naming convention that is required and then it simply works. Of course, when I say function, I mean method. Old habits are hard to change. Been coding for over 40 years.
This helped me out IMMENSELY! I recently asked how to learn the MVVM design pattern on Reddit, which directed me to Caliburn.Micro, which directed me here. I feel like I understand now! Funny story though... Part way through your video I accidentally hit the hotkey to slow the video down to 0.75x speed and thought to myself "Man, why did he decide to start sounding all condescending"? Caught it, turned it back up and laughed! Great video!
Great resource! You say at about 19:32 that "the entire thing is the user interface". Does that mean the business logic happens outside the three M, VM, and V folders we create?
Very great tutorial and instruction. Similar in style to a fantastic instructor I had a few years ago, you'd probably do well in classroom instruction. Only thing I was a little disappointed there was no touching on dealing with multiple windows in Caliburn, but you gave enough of a foundation that I can reasonably understand the results of my searches now. Even feeling reasonably proficient with C#, without much familiarity with XAML and zero with Caliburn search results / stack overflow read like Greek!
I work with multiple windows in Caliburn Micro/WPF in the TimCo Retail Manager series here on RU-vid: ru-vid.com/group/PLLWMQd6PeGY0bEMxObA6dtYXuJOGfxSPx
awesome everything ok until 1:17:31 I got an error the method ActivateItem() does not exist in the current context. I tried to continue ignoring the error but it keeps there.I'm inheriting from Conductor. There's a method called *ActivateItemAsync()* i tried it but it doesn't work. Help please
ActivateItem (at 1:17) is replaced by ActivateItemAsync public async Task LoadPageOneAsync() { await ActivateItemAsync(new FirstChildViewModel()); } You can, but don't have to replace
This is really helping me with a greenfield project that I'm handling all by myself which was extremely overwhelming, this is literally putting food on my table. Thank you.
All of them will work well. I recommend Caliburn Micro because I like how it is set up and the opinions it has. I don't do anything in my videos that I don't recommend for production unless I very clearly state that.
OMG Thanks a lot, i do in 1 hour something a i take 2 days just setting up the project, i feel i was trying run before even learn to walk. cal and you save my life.
Wow, this seems Brutal for making GUIs. All that XAML typing and work just to add a combo box and some test. Holy cra* man. No thanks!! I'll stick with VB6 and WinForms. 0.o Can't I just drag and drop a combobox width and a text label??? Good grief man. This was a great video to show me why I never want to use WPF! Hahahaha.
So, Caliburn Micro saves you few characters on every binding, but takes away all the refactoring features of strongly typed language of C# + XAML. Not nice :) when you setup DataContext in XAML, you get full InteliSense on ViewModel properties in bindings.
@@IAmTimCorey I am sure it did much more, but binding by name convention seems odd. If i rename a view model property, i have use text search to change all bindings. I know from experience that I often use the same names in different view models (like IsBusy), so I would have manually check whether given IsBusy is from correct view model. I am aware that with Calibur Micro I could just use unique names, but we all know how that ends , especially in a team. Great video though, I watched it all which is weird since I don't like the technology. Thanks :)
@IAmTimCorey It's a little unfair to be getting this kind of criticism on a very informative video you went through the effort to make several years ago. I appreciate your optimism and maturity in regards to unnnecessarily callous comments however I think people like *squints at name* @スリンキ--Slinky need to put the keyboard down and watch your video titled "Caliburn Micro Is No Longer Being Maintained. Now What?" before chiming in. I for one will be scouring your video list for other MVVM framework examples to determine whether or not my next cross platform IoT project, that utilizes C# in the Windows portion of the software, will be using something other than Caliburn Micro. I don't mind the difficulties that came with wrapping my head around this framework, but I do recognize its shortcomings. Either way please know that your work here in this video is deeply appreciated and will be useful long after .NET becomes incompatible with this sunsetted framework.
Yep, there is a lot of good stuff in those design patterns. The key is to not go too crazy with design patterns so that you make a simple application overly complicated. As always, balance is key.
Am i the only one that hates frameworks that do all that sort of automagical stuff just by having things named certain ways? I kinda like manually connecting the parts and eg telling which viewmodel connects to which view, rather than letting some framework try to figure it out...
Nope, you aren't the only one. I'm normally not a proponent of them but I make an exception in this case because of the adoption of it, how easy it makes MVVM, how much it provides that I would otherwise have to do myself, and the long-term support it has been given. But I totally get doing it yourself so there is no magic.
I hate also this kind of framework. I will not use it in my WPF project. Learning WPF is enought work (it worth it), therefore I dont want to learn a framework to be used for another framework (WPF).
Thanks Tim, you are literally doing miracles with your tutorials keep it up. I would like to see you do a start to finish payroll tutorials, analysis especially, thanks.
Excellent video on the MVVM topic! I would love to see another fantastic video where Tim designs his own MVVM framework without using any third-party libraries.
Tim, so much thanks. This video is 100 % accurate for the purpose. The speed and the organization of content is just exact. I learnt a lot. I was able to build what I wanted to build by following every second of this video. Each second of the video was only helpful. I am going to refer all your other videos for my requirement of learning and building.
Can't thank you enough for this video. I always had issues with tying some of the concepts of MVVM into practice, but after watching this and implementing the demo myself, I feel i have a much better understanding. Time to get working on refactoring a ton of old code.
Went through your Fundaments intro into wpf and it wet my whistle enough to learn more before moving on. Looking forward to the new things I can do with it.
Finally a Video worth watching! Literally watched it from the beginning till the End. Really appreciated thanks alot. Unlike other Many videos well explained.
Please help me, I opened a new view in Content Control and added a button there to change this view to another one, for example to page 2, but in ViewModel I can not call Activator again. Because there is a Screen inherited there and not a Conductor, Tell me how to switch to another a page from FirstViev in SecondViev
Great work Tim,you made it very easy to understand, the active item thing made my life much more easier. i as a beginner was creating new instance of a user control everytime i want a new page and having a goback button in the new page now.
Love the video. Makes learning a lot more simple and enjoyable - please keep up the fantastic work! :-) Found something about Caliburn Micro connections/associations that I think is worth noting. 1:04:53 "Since we pass into the ClearText(), we can also pass into the CanClearText()" However, it looks like we don't need to pass firstName and lastName into CanClearText(), using the corresponding public properties instead: public bool CanClearText() { if(String.IsNullOrWhiteSpace(FirstName) && String.IsNullOrWhiteSpace(LastName)) { return false; } else { return true; } } works just fine. The ClearText(), for it's purpose, does not need those parameters passed in - BUT IF WE DON'T pass those parameters into ClearText(), CanClearText() just does not get invoked (and naturally, the button auto-disable/enable doesn't work). So, it looks like passing the seemingly unnecessary parameters to ClearText(string firstName, string lastName) actually establishes the "magic" link between changes in FirstName/LastName and CanClearText(). Pretty counter-intuitive if you ask me :-)
I really liked this video. This actually encouraged me to create my own version of caliburn micro which has some features that caliburn micro does not have.
As an Android developer who also likes MVVM this looks really clean. Looks a lot nicer than the implementation we use over in Android land, very structured.
Hi Tim, like everyone else I am so so very grateful for all your hard work on producing your videos. You are now my go-to resource and I don't know what I'd do without you. Quick question, I've seen your more recent video about moving to MVVMCross, as it had been announced that CaliburnMicro wasn't to be supported anymore. I'm about to start a new WPF project, I see that Caliburn seems to have been updated relatively recently (version 4 and subsequent fixes I'm guessing). Is it still a sensible choice?
A great scratching of the surface ... makes me want to look deeper on down. There are things other than combo - text - labels and buttons that I really need to look into. Course add on purchased!
Thank you, it was a bit slow because of some parts with no relation to MVVM or Caliburn Micro (like the rows and column definitions etc) but it still helped me to learn how to start with MVVM.
Great work Tim. You are one of the best. I suggest that you make a full detailed course about Caliburn Micro. Such course will be a hit, and I definitely will buy it. Keep on the good work.
I was getting so frustrated because the program didn't want to do what it was supposed to do. I changed the Caliburn.Micro from the newest version to 3.1and it worked. Programmers struggle I guess. :D Thank you for all that you do.
Thanks, I wanted to check out MVVM and this was a great place to start. I worked through it with the older CM 3.x versions and then upgrade to 4.x which wasn't too difficult beyond changing to use the async methods.
Thank you so much Tim. I'm going plan to switch my company framework from MFC to WPF (My company still hold an very old framework). This is very good reference and start for me. Thanks
Nice Tutorial, I just want to learn some frontend technology, I have unity3d background, I want to learn some other front-end tech, want to choose WPF, electron, or browser app using js, ts or react. But finally I see your video and decide to learn WPF, thanks for your great effort.
Hello sir thank you , you don't know how lucky I am to find your channel and find great teacher such as you , I live in third world country and having access to your videos really changed my life , you are one of if not the only reason I love C# . your way of teaching it really blows my mind .the fact that you keep going back to your 4 yo videos and answering questions shows that you are guy with great character . I've been helping my friends and teaching them C# , and every time they ask from where I learned all that i point them to you, i learned lot of stuff from you not only programming but also the way you slow talk when teaching again thank you . And i have question , do you think Caliburn Micro is good choice in 2021
It depends. If you don't mind staying with .NET 5 and below then yes, I think it is a great option. Otherwise, you need to think about other options like MvvmCross or Prism.
I would push back on the obsolete comment. This code is still valid and fully supported by Microsoft to this day (and beyond). Also, businesses don't work only on the latest version of .NET. There are a LOT of developers out there working on older versions of .NET and the .NET Framework.
Great vid! Caliburn Micro seems very powerful, it automates a lot of things. But I would have preferred a more classic approach to MVVM (without Caliburn). Since Caliburn does a lot of things behind our backs, it also has the disadvantage of preventing us from really pinpointing aspects of the MVVM, which is just my opinion, but Caliburn should be used AFTER mastering the "classic" MVVM.
Tim, thank you so much for this amazing video. I'm finally starting to understand MVVM and I'd be very grateful if you could talk a little more about Caliburn.micro. 😁
I'm glad you enjoyed it. I'll be using Caliburn Micro in the future for other WPF videos but in the meantime, I did create an add-on course for my C# Application from Start to Finish course that is 7 hours of Caliburn Micro content, in case you are able to purchase it. If not, no worries, more content is coming in the next few months.
Great video. An addendum to this. You can use the normal binding for anything. Thus you could use if you want. This is useful if you want to change the Mode or the UpdateSourceTrigger so the button updates on every keypress. HOWEVER - if you do this and want to use the property in a guard function (CanXXX), you STILL need to name at least one object for this property in the page/control using the Caliburn Micro conventions. If you use a CanXXX property and handle the NotifyPropertyChanged yourself, it isn't an issue. That is why I usually use the property version of the guard and keep track of the notify's myself. The advantage is that if a button isn't disabling, I usually will look in my ViewModel first. If I am there, I don't need to open a second file. I just thought this might save someone a little time.
Followed through this, and found it extremely interesting. Thank you! It would seem the pitfall here is the way that everything hangs together based on 'names "hooking up" ' and the mechanism thereby "works" . . . but that the application still builds fine if there's a typo in the naming that breaks the mechanism(s). This seems a slight retrograde step from WinForms, where a typo usually results in an immediate "yell." (For example: one could envisage mayhem if some text replacement operation to the source-code was botched: everything still builds OK, but the some of the functionality driven by the naming stops working). Perhaps in later installments you might be addressing those sort of concerns, but this comment is obviously coming from a very ingenue perspective. WPF certainly opens up some interesting UI ideas. Thanks again.
Hi Tim, I love your explanation and patience. I'm a .NET / WPF Rockie Dev but I hope to get used to it soon. Just for the record, try not to do large videos because it's kinda difficult to follow the subjects. 20/25 min per videos will be fine. Thanks a lot.
The problem with setting a timer on a video is that I then have to cut out things that are important but don't fit into the timeframe. I can't be patient and explain things and also meet a set deadline. I try to avoid overly long videos but at the end of the day, time isn't my biggest concern.
Thanks Tim, again very good video and explanation. It would be great if you do a second part. For example explain where I put functions and do my logic stuff. Cause I have some trouble to understand where to fill the BinddableCollection when I don't want to do that in the View Model.
Is it best practice to add a ViewModel for the User Control? There is a lot of people who argue that a User Control should NOT have it's own ViewModel. This makes sense for simple applications. But for large applilations I find it benefisuial to add a ViewModel to make "Parent" ViewModel a bit simpler. What is your recomendations?
the way you explain things make it very easy for me to understand 👏 you R awesome 😁 one problem im facing right now is when i use NotifyOfPropertyChange i got this error : " The name 'NotifyOfPropertyChange' does not exist in the current context " even that i added *using Caliburn.Micro;* same error still happen . im using .net Wpf
Hi Tim, What is your opinion/solution to the following problem: At work im mainly creating WPF desktop applications and many guides and frameworks tell me to create two folders /ViewModels/... and /Views/... but when my application gets bigger there is always the point where my two folders get really big and there is almost no connection between the views in the view folder and the viewmodels in the viewmodels folder (except for some base classes of cource). So my thought on this was/is that a viewmodel and its corresponding view should be placed side by side in one single folder (e.g. MVVM/AddUser/AddUserViewModel.cs and MVVM/AddUser/AddUserView.xaml) . If I change one of them the other one often has to change to therefore placing them in the same folder combines them logically.
Hello Corey, thanks for the tutorial.I have seen the code and looks like you do not place any code in the view at all. I have a few questions here. 1. I wonder how do you handle events in MVVM pattern? For instance, hover, double clicked, mousemove, mouse click at imagebox and etc ? Simple way is to write code in View but that's not MVVM right? 2. In MVVM, How do you change control's property (enable/disable button, change background color, change label's text, disable entire user control view and etc) based on events (if I implement state machine) or change control's property based View Model's property change? (Eg. if false, change color, if true, change another color etc). It's a lot easier if i just get the view's control (button_name, label_name)in View. But MVVM basically prohibits codes in View right ? 3. Also, Is User Control itself consider a View? Some people from stackoverflow basically disagree with it. Therefore, they said User Control should not have it's own ViewModel, they said managing data flow will be a lot harder if all user control have its own ViewModel, and doing this basically defeat the purpose of MVVM. This basically contradicts your example where you also create 2 ViewModels for FirstChild & SecondChild 4. Last but not least, based on your example, if we agree that each User Control also should have its own ViewModel, then how can we communicates among these ViewModels ? Example, I have a user control that have buttons to control program state machine, and I have another user control with textbox to display what is the state that the program currently at. You are one of the youtuber that's very active in teaching c#, I will take your opinion and answer seriously. Looking forward to your response.
Events are methods in your VM. As for changing things, you can bind any item to a property (so color could bind to a property in your VM). Yes, in CM a UserControl is a View because that is how we use it. How you use it makes it either a View or not a View. Cross communication can be done via events. Check out the TimCo Retail Manager to see that in action (the login control triggers the Shell to load a different page).
Hi Tim! I had a little question. When you make this ComboBox in row 3, you use Mode=OneWayToSource saying that it will overwrite the property. But I didn't understand what exactly it'll overwrite there? Aren't we still pulling names from property just like we did in TextBlock in row 1?
Dear Tim, Thank you for this phenomenal tutorial. It is a pure gold, i have to say! I have one dummy question: private BindableCollection _people = new BindableCollection(); public BindableCollection People { get { return _people; } set { _people = value; } } Why in the constructor we are using People.Add(new PersonModel { FirstName = "Tim", LastName = "Corey" }); instead of _people.Add(new PersonModel { FirstName = "Tim", LastName = "Corey" }); What is the difference? Thank you in advance and keep up the good work! Vasko
We use the public version of the property instead of the private backing field in order to keep any logic in place. Basically, we avoid ever touching the private backing field outside of in the property itself. That way, if we protect what can be set or what the user can see, those protections are not bypassed.
