Hey Brian, I finally got my first job as a WPF developer, I'm so excited. They really like that I'm was/am studying the Prism Library. And I'm keep learning so much from this series!!
Hey Brian, about that IList to List confusion at around 45 minutes in... you can't implicitly cast an abstract type into a concrete type because that would "widen" the interface to the underlying original object that could have a completely different implementation than what you'd expect, and there be dragons. So kudos to the compiler for not allowing that even though in this case we all see that it's the same thing. I'm not yet done watching this video so I don't know if it struck you later on 😁 if it did, just ignore my comment. Nice series btw, thanks for that! 👌
Thanks for the clarification on that behavior. I never really thought about it, but it makes complete sense now that you pointed it out. Let me know if anything else jumps out at you.
44:34, It's cleaner to check that they don't exist in the cache then to check if they do. If they don't exist in the cache, then create and insert them into the cache. After that bit of code, you just have code that assumes that the cache exists because it does. This is a single threaded method here, we don't need to worry about race conditions. This turns that if...else into just an if-statement. Also, that var was of type 'List'. An 'IList' doesn't have to be a 'List' which is why you can't assign an 'IList' to a 'List'. It's find to do it the other way around because a 'List' is an 'IList'.
Hello Brian, thanks for your valuable content. I suggest including the DependentView attribute and the region behavior internally in the prism library as a feature included within the library (battery included).
5:37 On specifying ribbon tabs with view class attributes 6:13 On regions 6:29 On region adapters 6:58 On region behaviors 7:25 On using a region behavior to read the attributes of a (primary) view and use them to inject (secondary) views into other regions in the window 8:50 Creating the DependentViewRegionBehavior class by deriving from Prism.Regions.RegionBehavior 9:16 On region Views and ActiveViews collections 13:26 Registering the region behavior 13:44 Adding BehaviorKey to the behavior 14:44 Alternative 1: Registering a region behavior with a region adapter 16:39 Alternative 2: Registering a region behavior for all regions 18:17 Testing the region behavior registration 18:50 On how DependentViewRegionBehavior is going to work 21:09 Creating GetCustomAttributes method 25:54 Creating DependentViewInfo class 28:43 Creating CreateDependentViewInfo method
@@BrianLagunas Hey, thanks for the videos! Sorry I didn't finish this TOC, but I really got stuck on how to manage the tabs in my own particular situation, which is a bit different from what you did for the Outlook client. So I got sidetracked and never came back to it. I still haven't got it fully figured out so I'll probably watch this again later and finish the TOC.
Hi Brian, just want to say this is a great series and I learn a lot! Have I understood it correctly that the region behavior is being run when any region in the app will ether add or remove an active view? Wont that cause a performance issue with large apps with many regions? Second, is the event handler added during initializing of the region?
In this specific case, the behavior will run anytime a view is activated in the region. It shouldn't cause any perf issues because the code it is running is not complex and it's fast. We're not calling out to web services or using anything that causes a delay in our code. When you create a region behavior you must understand how they work and keep in mind that you may need to put in logic to control when that behavior logic runs. Yes, the event handler is added when the region is first created.
Hi! What if I am not using control with e.g. SelectionChanged property, so I can't track changes like you did with XamOutlookBar SelectedGroupChanged. I could hardcode in code behind every button separately, but I am working in MVVM pattern, so I want keep code behind views simple as possible :)
Amazing series! Great great job Brian! I'm learning a lot 🙂 One question: What is the best way to have a single instance of a viewmodel for different views?
Your exceptions at closing the window may caused by XamRibbonWindow. I follow your videos and I am reimplementing your code by myself with the controllers you use in trial mode. When I click the close button of this window controller the window sometimes does not close and VS freezes for a short time but I do not get exceptions. It is wierd but I feel like there can be the reason of the problem.
I don't understand this RegionBehavior stuff. I don't understand what the difference is between the ribbon tabs and the MailList view that made you want to make class Attributes for the tabs. The RegionAdapter should shield you from caring how the view gets into the region, so is the difference due to a leaky abstraction or something? The tabs just seem so much more complicated than what you did for injecting the MailList view.
I agree, I don't think you have grasped what's going on. The region adapter doesn't care how the view gets in the region. If you look, the region adapter does nothing but add views into the region. What we are doing is allowing a view, such as the MailList view, to automatically inject related views (in this case ribbon tabs) into a separate region by using a region behavior. There is no leaky abstractions going on at all. Everything is properly abstracted.
@@BrianLagunas If you weren't going to do it _automatically_, how would you do it manually? I don't see what it is you're trying to avoid with the automation. I want to know if automation is suitable for my app, or if manually would be better.
@@mgregory22 Doing it manually would be a very complex, and difficult to code scenario. Keep in mind, we are doing more than just adding tabs into a different region. We are also sharing the DataContext between the view in the content region and all the tabs in the ribbon region. We are removing them as we navigate away, and caching them so we don't recreate them when we navigate to them again. Honestly, I don't know how I would do that "manually". Not only would you have to track which view is being navigated into the main region, but you would would have to know which tabs to create for that specific view, somehow make sure you are sharing the data context, and then inject the tabs into the ribbon region. I would not wish that on my worst enemy :). Then, you have to make sure you know how to remove the regions from the ribbon region when a new view is navigated to, while repeating the process for the new tabs. While you're at it, you would have to create a caching mechanism to ensure you are not recreating the tabs gain if navigating to the same view. Most of the time "automated" is always better than "manual".
@@BrianLagunas Sorry, I didn't see your reply. In this part of the previous video in this series (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Vm8cknEgYr0.html) in the MainWindowViewModel, you have a method called ExecuteNavigateCommand, and in there you call _regionManager.RequestNavigate(RegionNames.ContentRegion, navigationPath);. My understanding is that this loads the view specified by navigationPath into ContentRegion. So why can't you just type _regionManager.RequestNavigate(RegionNames.RibbonRegion, navigationPath); on the line directly after that and just inject a view into the ribbon as well? I know the navigationPath is going to be holding the name of the view that goes in ContentRegion, but can't you customize the RibbonRegion so it interprets that view name differently and loads the tab associated with that view? I guess when I see a URI-based system, I think of a routing table that you can use to direct the URI's wherever you want, but I guess Prism would need a routing table for every region, so maybe it doesn't have that.
@@BrianLagunas You Help Me Solve so many Problems, and teach me so many ways to programming, decoupling, I love that ,I have so many question to ask , I Wacth your video whole day !!!! really , from I get up to sleep.
