Forums | NoesisGUI

Hello,

Being a WPF/xaml rookie, I've got numerous questions and areas of confusion, so bear with me while I ask a few of the most pertinent here pertaining to the Inventory sample:

1. It is my understanding that the DragAdornerBehavior, being applied fairly high in the element hierarchy in the xaml, actually applies to all UiElements. E.g. even the slots (head, ring, chest, etc.) where the inventory items can be dragged to, will have the DragAdornerBehavior applied to them. I'm assuming this is intentional, but I would have thought this behavior is only relevant to apply to the inventory elements themselves (sword, shield, ring), no?

2. The complete drag and drop behavior is spread over multiple objects/elements including DragAdornerBehavior, DropItemBehavior, DragItemBehavior. Assuming I want the ability to reposition lots of widgets arbitrarily within a single canvas, i.e. not into explicit slots, is it possible/reasonable to combine all of this code into a single Behavior?

One problem that comes to mind for me, is that the position of UiElements' is sometimes determined by the parent element, but looking into DragAdornerBehavior - which simply references its current position with an offset - this doesn't seem to be an issue?

3. The item being dragged is rendered under the mouse cursor by applying TranslateTransform and assigning DraggedItemX, DraggedItemY to the x,y position of the object, respectively. As an extension to the previous question, is this 'best practice'? Would it be feasible to instead have the rendering x/y offset set by the backend code?

4. Why do some callbacks have 'Preview' prefixed to them? E.g. PreviewMouseMove, compared to DragOver, or Drop?

I hope these questions aren't too silly.

Thanks in advance,
Gazoo

1. This behavior is placed on the root element of the xaml so it has an associated element that covers the entire screen, because the objective of that behavior is to provide coordinates for the dragged element so an overlay can be rendered in the correct position when dragging.

2. The different behaviors represent the qualities we want to expose: an element that can be dragged, or an element that can be used to drop another element. In your canvas example, the different widgets will use a DragItemBehavior, and the canvas will use a DropItemBehavior. Assuming you only want to drag the widgets inside the canvas, the DragAdornerBehavior can also be applied to the canvas, so dragged element coordinates are relative to that canvas (you won't need the Drop code in that behavior, though).

3. This is done this way to have a reusable behavior that provides the dragged element coordinates, because the behavior has access to the associated UI element and can register to the DragOver event to update them. If you want to expose those coordinates from the backend code you will need a way to get a target element and to hook to the DragOver event, and that will probably break the MVVM separation.

4. Please take a look at this post to have a better understanding on how routed events work: viewtopic.php?p=9362&hilit=bubbling#p9362