Sorry for being unclear... I did not mean forcing single selection, even for keyboard navigation. I think we are all in agreement that multiple selection is a must for this control.

In order to implement keyboard navigation correctly however, the user needs to know where the selection focus lies within the control when looking at it. Currently, items can be highlighted simultaneously in both the source and destination lists:

Sorry for being unclear... I did not mean forcing single selection, even for keyboard navigation. I think we are all in agreement that multiple selection is a must for this control.

In order to implement keyboard navigation correctly however, the user needs to know where the selection focus lies within the control when looking at it. Currently, items can be highlighted simultaneously in both the source and destination lists:

When looking at the control in this state, users would not know where the focus currently lies; they would be left guessing what would happen when hitting one of the arrow keys.

Well, I can see how it might be ambiguous with ranking, though it could be understood that the ranking would get applied to any items that are selected. However, with moving items from one list to another I think it's much less ambiguous. After all, you can only move items from the left to the right with the right arrow button and vice versa.

Any and all code samples that are authored by me and posted on the Ext forums or website are hereby released into the public domain and I release anyone or entity of liability by using said code samples unless explicitly stated otherwise.

Opinions are mine and not necessarily endorsed by Ext, LLC. Please do not contact me directly for assistance unless requested by me.

1) When an item or items are moved from the source panel to the destination panel, the dragged layer must be contain a graphical represention or number (and text) eof dragged items. (See image1 and image2). Posibilty to insert items in specific positions.

2) Instead of using images for the buttons as a whole, instead they should use icons and be Ext buttons. Enable/disable arrows buttons based on selection (or lack of it).

Shouldn't we agree on a single definition of a DraggableView/DDView so that the Ext.ux package is self consistent?

Yes I agree. Happy to use yours. Only drawback I see is dependencies for the end user ie. anyone that wants to use ItemSelector has to download DDView...on second thoughts maybe that's not a big deal as long as it is made clear.

Originally Posted by Animal

One thing I noticed that was a "bug" in my Ext.ux.DDView, and still shows, is selection order.

If you click the bottom element, shift click the top element, and then drag them over, the order will reverse. Selection order becomes the actual element order.

I'm planning (public holiday here today) to change getSelectedItems to loop through the Store in its natural order, calling isSelected on each Record, and push it onto the Array if it is selected. That will keep the order the same.

One thing I noticed that was a "bug" in my Ext.ux.DDView, and still shows, is selection order.

If you click the bottom element, shift click the top element, and then drag them over, the order will reverse. Selection order becomes the actual element order.

Animal, I don't think that is a bug. I think that is the correct behavior. It allows for you to reorder, without having to reorder. What I mean is, the order in which you select the items is the order in which they are dropped.

Please don't remove that "feature" as I think it has quite a few valid use cases and many users might like it (like me ).

Most of the time, I want the visual order to be mantained. If I click on the bottom element first, and shift-click on the top, and then drag, I don't want my Components in the Menu in reverse order of what I see.

I can see the utility in being able to actually select in order and have the elements drop in that order.

I will update my DDView class today with an option to preserveSelectOrder with default false.

but the line "var tr = table.createChild({tag: 'tr'});" is not creating a tbody by default as it does in IE n Firefox so when we do "tr = tr.child('tr'); " . it gives an error ...cannot convert from undefined to null to an object .....