This project is read-only.

Drag'n Drop Methodbinding and more

Jul 24, 2013 at 8:01 PM
Hi, this is great component, but i found several small issues:
  1. BorderSelectionAdorner line 32 - if there is no adorner layer (it was my fault with new window template), it throw object reference not set...
  2. Why you use System.Windows.Control namespace? I see no reason for this, but I see, that changing it now is so late.
  3. MethodBinding for D&D operations is strage (as you write in comment)
    I see why you dont want to use some interface (dependency of VM to component).
    But why not to use Commands and binding?
bool CanDrag(), void Drag():
ICommand DragCommand;
object DragSource //bindable
call DragCommand.CanExecute()
and then DragCommand.Execute(), which will fill DragSource property via Binding
bool CanInsertFormat(index, format), bool CanInsert(index, data), void Insert(index, data):
ICommand InsertCommand
int InsertIndex //bindable
set InsertIndex to index
call InsertCommand.CanExecute(IDataSource)
and then InsertCommand.Execute(IDataSource)
bool CanDropFormat(format), bool CanDrop(data), void Drop(data):
ICommand DropCommand
call DropCommand.CanExecute(IDataSource)
and then DropCommand.Execute(IDataSource)
what do you mean?
I will try to implement this, if you wish, i can share the result with you.

Cheers, Jan
Jul 26, 2013 at 11:32 AM
  1. I dont understand your first point is there a problem or was it just a mistake?
  2. Using this namespace has no specific reason. It is as good as any other namespace. At least I dont know any.
  3. Actually I had implemented a version using commands. But writing the sample I saw it resulted in writing far more code, than the current solution (RealayCommand If you dont have one, the properties for the command, the init of the properties). So the user has to write less code now and probaly wont realize a loss of performance, because the can-methods are only called on mouse move. I think the solution is ok, dont you?
Regards, Torsten
Jul 27, 2013 at 8:58 PM
Hi, thank you for answers.
  1. I think that as many places in code as it is possible has to check errors. I have referenced only dll and I didnt know what is wrong (when it sometimes throws "Object reference not set"). So my recommendation is to check result value of GetAdorner to null and throw better error ("No adorner layer found" for example).
  2. Ok, my opinion about namespaces is to avoid conflicts. So namespace has to be unique to author, "Slompf.Components" for example. And some components are also using "Systém.Windows" and I didnt know, why are authors using it. If there is no specific reason, i got my answer. Thanks.
  3. Ok, again, my opinion is that in MVVM I am using some common concepts, including notification changes and commands for all the things. If you are trying to create new concept - methodbinding, any reader of source code will at least be uncomfort with it. I was trying to help you, for example if you dont know command concept. But you probably do and you made a desicion - it is up to you.
Again, thank you for TreeEx and answers.
Cheers, Jan