ListViews - WPF DRAG DROP TUTORIAL #3

[@itbug7873]

Positive: Very good videos and really meaningful content and good best practice. Negative: I lose too much time to rewind to see what the author has written because it cuts off too short when something is finished and jumps to the next image. Sometimes I have to set the speed of the video to 0.25 to catch the moment when I can still see it.

[@gary6212]

Good tutorials but too much Aderall

[@CADInnovations]

Great video, this helped me immensely. Any tips on how to handle the drag event when the itemtemplate contains a combobox that still needs to be selectable (with this implementation, the combobox never drops down because the mousemove event has been applied to the entire listviewitem)?

[@MarkWithall]

Great video. It would be nice to see the item moving with the mouse when dragging, rather than just disappearing from the initial list and appearing in the new list.

[@SingletonSean]

Thanks Mark, and I agree! I'll have to look into this. I feel like I've been in codebases that have this functionality, perhaps Adorners are the answer here? Will experiment.

[@jm001-d3v]

@@SingletonSean If you ever figured this out, would love a vid on it. I've been scouring the internet trying to find a decent solution and information is scarce/outdated. Strange since I see it in half the apps I use...

[@mischaschmid259]

Realy Nice, thank you very much. I programming a Card game, and now are my Cards drag and drop able.

[@SingletonSean]

Awesome Mischa, sounds like a fun project!

[@Tyronblade]

Great video! Reordering like you said would be super interesting as well

[@SingletonSean]

Thanks TIRAN! I will indeed cover that

[@BeholdTheLight23]

lol, and a video about what I'll be needed in the next few weeks... :D Thanks!

[@nikitatrunov2175]

Hi! How i can implement drag and drop without broken mvvm pattern and without using code behind ?

[@KiII4Game]

i know this comment is old at this point, but for any developers starting off with wpf, please please PLEASE understand that code-behind does not violate MVVM. it is a very powerful tool that is sometimes necessary to keeping MVVM in tact, like when opening up a dialog from the UI for example, which should be done in the view component (aka a code-behind) rather than in a view model component (like a command binding).

[@tjzIsMe]

How would you handle adding the item back to the original listboxt if it is dropped on a non-target such as the window?

[@SingletonSean]

Good question Joe! That will be the next video in this series

[@benedictpardo6366]

Can you please do a review on Material Design In XAML Toolkit??

[@gary6212]

9:00 Why would you (what is the advantage of) creating a two-way binding on the view model to pass the drop parameter data from the drop handler to the view model so that you can then access it via the injected view model in the command. Why would you not just pass that data via the object parameter on the Execute method (that is what it is for) and get rid of the seemingly unnecessary two-way binding code that is dirtying up the code and making it unnecessarily more complex. Also, what is the advantage of placing the commands in their own class and then injecting the view model into the command. I could understand doing this if the command was reusable in different contexts, but it isn't. So why the added complexity - it doesn't make the code more maintainable, in fact it does the opposite by cluttering up the code with a ton of unnecesary wire-up. The commands are tightly coupled to the view models they act on. If you put those commands in the view model, you would not need to inject the view model into the command. This isn't separation of concerns, this is the unnecessary fracturing of a single concern. If you want the commands in a different physical file from the rest of the view model, consider using a partial class.

[@SingletonSean]

Yes, I wouldn't recommend putting classes in commands. I'd recommend something like the MVVM toolkit for creating commands, which I talk about here 😄 kzbin.info/www/bejne/g5eceJeqdruIpbM

[@gary6212]

@@SingletonSean Not "putting classes in commands" putting commands in classes. You do it extensively in this series and comment that you are a big fan of classes for your commands. What about your use of dependency properties to pass values from the event handler to the command? What is the advantage? Why not just pass that value via the method parameter? Am I missing some hidden advantage that warrants such an exotic approach?

[@marvinalone]

it will be much better to show the item that is being dragged

[@gary6212]

9:43 another screen transition that is way too fast for any human to see, let alone follow along with

[@gary6212]

For the love of god, slow down, especially when you type something on a screen and then instantly change to the next screen - people are trying to follow along and learn. Your 16 minute video takes me over an hour to get through with all of the backtracking and pausing I need to do - and I am already watching it at 75% speed. I am a .net architect with 15 years experience; I can only imagine how frustrating it is for beginners. Checkout your transition at 6:19 - you cannot even physically see what you typed on the screen. It is like coding in a tornado.

[@SingletonSean]

My bad! This is like your 5th comment about it on this series, I get it 😂 Unfortunately I can't change this video, but I'll slow down and be more precise in future videos. Thanks for the feedback and for supporting the channel!

[@gary6212]

@@SingletonSean No problem. It is the 3rd; I am trying to provide you with concrete examples in an effort to improve you content. It is apparent you were not considering the audience's perspective - so I am attempting to provide you that perspective.