Hello! At 21:27 - using this approach creates strong coupling. Instead, you can add dependency in the constructor, like "Func statusInfoViewModelFunc", save statusInfoViewModelFunc in a readonly field (e.g. _statusInfoViewModelFunc) and call the _statusInfoViewModelFunc.Invoke() when you need to create an instance. Factory function injection is well documented in the Stylet documentation. I learned about Stylet from your other video. Thanks a lot for the great content!
I had an issue debugger was not allowing try/catch to handle the error and it was breaking earlier. What helped is restoring list in Exception Settings to the default. Debug > Windows > Exception Settings > Restore the list to the default settings
Hi Tim, nice video as usual... I wanted to point out that at 23:08 in the video you can remove the _window.ShowDialog call from the if/else and move right before the TryClose() so its not repeated. Keep up the good work.
For anyone interested: 19:26 Documentation docs.microsoft.com/en-us/dotnet/api/system.windows.window?view=netcore-3.1 CTRL + F "Appearance and Behavior"
Another great video, and a good way to use Messagebox from MVVM.. Personally I wouldn't even want the user to see the salespage if they don't have the permission, so maybe it would be possible to hide it before showing the messagebox.
Why didn't we just do an event and listen to it in the shellviewmodel? I thought that the shellviewmodel is responsible for overall view stuff and juggling viewmodels around (being the conductor and all)
I would create an Authorize attribute an implement the HandleUnautorizedRequest. Doing so allows you to handle all such unauthorized requests from a single point.
If you want visual studio to create the private fields with the leading underscore as shown in the videos. Here is a link that describes how to configure it in VS. stackoverflow.com/questions/45736659/how-do-i-customize-visual-studios-private-field-generation-shortcut-for-constru
Yes, the standard MessageBox breaks the MVVM principle. But since you're using settings, window size etc. here, doesn't that break MVVM just as much? Another thing: isn't the IoC.Get a Service Locator, which is considered an antipattern?
In the SalesViewModel, you didnt mark the private fields as private before, but in this video you added two more fields which are private and readonly. To be consistent, you should have marked the previous fields as private as well?
Great to see an example of a modal message box implemented in MVVM! Personally I'm not a huge fan of partially initialized screens showing messages at startup and then getting kicked out. What's the harm in putting the TryClose() before the call to ShowDialog()? It actually works and you only briefly see the Sales form doing it this way (but the modal dialog remains). eg. TryClose(); if(ex.Message == "Unauthorized") { _status.UpdateMessage("Unauthorized Access", "You do not have permission to interact with the Sales Form."); } else { _status.UpdateMessage("Fatal Exception", ex.Message); } _window.ShowDialog(_status, null, settings);
Putting the TryClose before the messagebox is hacky. It isn't guaranteed to work, even though it does sometimes. Ideally, we shouldn't even arrive at this page. We should be putting security rules in place to stop a link from being active if the user doesn't have permission to navigate to the given page. This check is just in place so that if they got to it anyway, they could not do anything. I prefer to add the logic in this order because then we know that the fallback works before we add in another layer.
The video next week will be on something that was released with .NET Core 3.0. I will definitely be doing more videos using it and the new things in it.
I saw the part of the video about not having messageboxes in view models. I actually found a mvvm friendly way to do messageboxes. I used it and it worked great. What I did was create an interface with a method called messagebox. Then wpf can implement it. I used it for xamarin forms and wpf and it worked great. the view model does not know how the messagebox will be displayed but whoever implements it can do what it wants to display a message box. What do you think of that idea? I used that in my mvvm framework and it still seemed to work great and the view models are actually in the .net standard library too with no reference to xamarin forms or any wpf stuff.
We want to allow the dependency injection system to create all of the instances. This allows us to put all of the creation logic in one place. Ideally, we would also ask for an interface instead of a strong type like we did here so that we could replace the implementation with a different view model if we wanted. That would break the dependency on the specific ViewModel.
Tim, I am doing this video 3 years late with the new version of Caliburn.Micro and many calls are now Async. Can you maybe address this in one of your videos, please?
Maby after serve 'unauthirozed ex' put line like this ((IConductor)this.Parent).ActivateItem(IoC.Get()); to not live empty form, but come back to login in this case.
Hi and thanks a lot Mr.Corey Please add azure devops CI/CD to project i love to learn how to add pipeline and CI/CD to project but i can't find really good tutorial like yours.
Hi again Tim! This video got me thinking: could project like this benefit and to be more future-proof if this sort of error checking would be done in the API layer? This could come in handy if one or more client applications gets added later to the project, so there's no need to build the error checking from ground-up in every front end client separately. This might require some sort of "shared connection class" using generics between API and all of the client applications which would then be used to transmit information about if there was some error in processing client calls in API and of course contain the actual objects handled by the calls. If there is need for language variants in client applications UI , the database could hold information about user preferred UI language and thus the error messages could be returned accordingly. This increases the data transmitted via the wire and server resource usage but i think it would greatly simplify the unification of different client applications. Thoughts about this? I realize these videos have been done for some time ago now and there's probably no chance for impacting the route of development in this project anymore by commenting, but i guess my comments (which i've been sending in a few lately) are more of a "would this be smart to do or are there some major draw-backs if i do it like this" type of questions. Any thoughts would be highly appreciated. I've been coding for 1,5 years now with C# (self / youtube taught :D) with just moderate previous experience with VBA programming in MS Excel. In front-end side i am most familiar with WPF since the project i've been mostly working with in these past 1,5 years is WPF project. Must say that i really like C# and the frameworks that MS provides. Really looking forward to getting into .Net Core and especially .Net 5.0. The .Net Stack really feels like i jumped to the right train considering all the effort MS is putting to all of the modern solutions like Blazor, Xamarin and the .Net 5 a whole not to mention Visual Studio. I'm currently trying to get familiar with .Net web based technologies in front and back-end so these videos of yours are truly invaluable for me! As always, got really inspired by your great tutorials! Keep 'em coming! br. Ville
Yes, you can do error checking on the API side and have it done once for all. However, you still want to do error checking on the client so that you aren't sending data to the server, getting it rejected, then updating the display. You want more real-time error checking as well.
Hello Tim! Great tutorials! I've followed this one from the beginnig and it has worked all the time - except from now. When i try: _window.ShowDialog(_status, null, null); in SalesViewModel, it fails with the exception: Exception User-Unhandled System.InvalidOperationException: 'The calling thread must be STA, because many UI components require this' This exception was originally thrown at this call stack: [External Code] TRMDesktopUI.Views.StatusInfoView.StatusInfoView() in StatusInfoView.xaml.cs and jumps to StatusInfoView.xaml.cs and marks the public StatusInfoView() I copied your code and everything work but this. Any idea of why? Can't find any solution online.
Hello! At 21:27 - using this approach creates strong coupling. Instead, you can add dependency in the constructor, like "Func statusInfoViewModelFunc", save statusInfoViewModelFunc in a readonly field (e.g. _statusInfoViewModelFunc) and call the _statusInfoViewModelFunc.Invoke() when you need to create an instance. Factory function injection is well documented in the Stylet documentation. I learned about Stylet from your other video. Thanks a lot for the great content!
I had an issue debugger was not allowing try/catch to handle the error and it was breaking earlier. What helped is restoring list in Exception Settings to the default.
Debug > Windows > Exception Settings > Restore the list to the default settings
Interesting. Thanks for sharing.
Thank you, same problem here - appreciate it!
Awesome video as always Tim!
Thanks!
Hi Tim, nice video as usual... I wanted to point out that at 23:08 in the video you can remove the _window.ShowDialog call from the if/else and move right before the TryClose() so its not repeated. Keep up the good work.
True. Good catch.
For anyone interested:
19:26 Documentation
docs.microsoft.com/en-us/dotnet/api/system.windows.window?view=netcore-3.1
CTRL + F "Appearance and Behavior"
Another great video, and a good way to use Messagebox from MVVM.. Personally I wouldn't even want the user to see the salespage if they don't have the permission, so maybe it would be possible to hide it before showing the messagebox.
Yep, that is possible.
Why didn't we just do an event and listen to it in the shellviewmodel? I thought that the shellviewmodel is responsible for overall view stuff and juggling viewmodels around (being the conductor and all)
I would create an Authorize attribute an implement the HandleUnautorizedRequest. Doing so allows you to handle all such unauthorized requests from a single point.
Thanks for the suggestion.
If you want visual studio to create the private fields with the leading underscore as shown in the videos. Here is a link that describes how to configure it in VS. stackoverflow.com/questions/45736659/how-do-i-customize-visual-studios-private-field-generation-shortcut-for-constru
Yes, the standard MessageBox breaks the MVVM principle. But since you're using settings, window size etc. here, doesn't that break MVVM just as much?
Another thing: isn't the IoC.Get a Service Locator, which is considered an antipattern?
In the SalesViewModel, you didnt mark the private fields as private before, but in this video you added two more fields which are private and readonly. To be consistent, you should have marked the previous fields as private as well?
Yep, I just forgot to set it.
Great to see an example of a modal message box implemented in MVVM!
Personally I'm not a huge fan of partially initialized screens showing messages at startup and then getting kicked out.
What's the harm in putting the TryClose() before the call to ShowDialog()?
It actually works and you only briefly see the Sales form doing it this way (but the modal dialog remains).
eg.
TryClose();
if(ex.Message == "Unauthorized")
{
_status.UpdateMessage("Unauthorized Access", "You do not have permission to interact with the Sales Form.");
}
else
{
_status.UpdateMessage("Fatal Exception", ex.Message);
}
_window.ShowDialog(_status, null, settings);
Putting the TryClose before the messagebox is hacky. It isn't guaranteed to work, even though it does sometimes. Ideally, we shouldn't even arrive at this page. We should be putting security rules in place to stop a link from being active if the user doesn't have permission to navigate to the given page. This check is just in place so that if they got to it anyway, they could not do anything. I prefer to add the logic in this order because then we know that the fallback works before we add in another layer.
.NET Core 3 releases today, will you be doing any videos related to it?
It's candidate release. Not final.
It releases during .NET Conf which is in a couple of hours
The video next week will be on something that was released with .NET Core 3.0. I will definitely be doing more videos using it and the new things in it.
@@IAmTimCorey i would love if you talk about the advantage disadvantage of blazer and jquery. thanks!
I saw the part of the video about not having messageboxes in view models. I actually found a mvvm friendly way to do messageboxes. I used it and it worked great. What I did was create an interface with a method called messagebox. Then wpf can implement it. I used it for xamarin forms and wpf and it worked great. the view model does not know how the messagebox will be displayed but whoever implements it can do what it wants to display a message box. What do you think of that idea? I used that in my mvvm framework and it still seemed to work great and the view models are actually in the .net standard library too with no reference to xamarin forms or any wpf stuff.
Interesting idea.
Nice use of Dependency Inversion from SoliD principles (Higher level code does not depend on lower level details)
Hi Team, what's the difference between IoC.Get() and new StatusInfoViewModel();
Didn't get it yet ... For me, both do the same. Where am I wrong?
We want to allow the dependency injection system to create all of the instances. This allows us to put all of the creation logic in one place. Ideally, we would also ask for an interface instead of a strong type like we did here so that we could replace the implementation with a different view model if we wanted. That would break the dependency on the specific ViewModel.
@@IAmTimCorey Gotcha! Got it! Thanx :-)
Tim, I am doing this video 3 years late with the new version of Caliburn.Micro and many calls are now Async. Can you maybe address this in one of your videos, please?
We address it in this video when we upgrade. That’s part of the goal with this app.
HI Tim, I've just began watching you and have a question (maybe someone asked before) - what're your comp specs?
Custom computer - Intel i7 with 32GB of RAM and a 512GB M.2 SSD.
Maby after serve 'unauthirozed ex' put line like this
((IConductor)this.Parent).ActivateItem(IoC.Get());
to not live empty form, but come back to login in this case.
Thanks for the suggestion.
Hi and thanks a lot Mr.Corey
Please add azure devops CI/CD to project i love to learn how to add pipeline and CI/CD to project but i can't find really good tutorial like yours.
Thanks for the suggestion.
Hi again Tim!
This video got me thinking: could project like this benefit and to be more future-proof if this sort of error checking would be done in the API layer? This could come in handy if one or more client applications gets added later to the project, so there's no need to build the error checking from ground-up in every front end client separately.
This might require some sort of "shared connection class" using generics between API and all of the client applications which would then be used to transmit information about if there was some error in processing client calls in API and of course contain the actual objects handled by the calls. If there is need for language variants in client applications UI , the database could hold information about user preferred UI language and thus the error messages could be returned accordingly. This increases the data transmitted via the wire and server resource usage but i think it would greatly simplify the unification of different client applications.
Thoughts about this?
I realize these videos have been done for some time ago now and there's probably no chance for impacting the route of development in this project anymore by commenting, but i guess my comments (which i've been sending in a few lately) are more of a "would this be smart to do or are there some major draw-backs if i do it like this" type of questions. Any thoughts would be highly appreciated.
I've been coding for 1,5 years now with C# (self / youtube taught :D) with just moderate previous experience with VBA programming in MS Excel. In front-end side i am most familiar with WPF since the project i've been mostly working with in these past 1,5 years is WPF project. Must say that i really like C# and the frameworks that MS provides. Really looking forward to getting into .Net Core and especially .Net 5.0. The .Net Stack really feels like i jumped to the right train considering all the effort MS is putting to all of the modern solutions like Blazor, Xamarin and the .Net 5 a whole not to mention Visual Studio. I'm currently trying to get familiar with .Net web based technologies in front and back-end so these videos of yours are truly invaluable for me!
As always, got really inspired by your great tutorials! Keep 'em coming!
br. Ville
Yes, you can do error checking on the API side and have it done once for all. However, you still want to do error checking on the client so that you aren't sending data to the server, getting it rejected, then updating the display. You want more real-time error checking as well.
Thank you
You are welcome.
Hello Tim!
Great tutorials! I've followed this one from the beginnig and it has worked all the time - except from now. When i try:
_window.ShowDialog(_status, null, null);
in SalesViewModel, it fails with the exception:
Exception User-Unhandled
System.InvalidOperationException: 'The calling thread must be STA, because many UI components require this'
This exception was originally thrown at this call stack:
[External Code]
TRMDesktopUI.Views.StatusInfoView.StatusInfoView() in StatusInfoView.xaml.cs
and jumps to StatusInfoView.xaml.cs and marks the
public StatusInfoView()
I copied your code and everything work but this. Any idea of why? Can't find any solution online.
Not sure why you are receiving this issue. I don't remember triggering this on a different thread, but that is what it sounds like is happening.
After a good night's sleep it started to work without doing any changes! Strange!
still waiting for next 2 videos
New videos in this series come out about every other week.