>>>Well, for the mover functionality it is easier to manipulate the arrays than cursors - that's why (IMHO) most of them are array-based. In my mover class that you tried, I had save and restore selection functionality before, then I dropped it because it overcomplicates the class (probably unnecessary in most cases) and users' understanding on how it should work is different.
>>
>>Nick,
>>
>>If you have class, which has:
>>1) Auto-resizing (simple enough)
>>2) Drag+drop in addition to buttons
>>3) Multiselect
>>4) Ability to show several (say, three) columns
>>5) Save+Restore ability
>
>>
>>and you can share this class with me, I would really really appreciate it.
>
>Well, n-tier grid + GridDragDropper 2.0 may do this. :)
>
>Actually, there are many issues to resolve before you can create a generic multifunctional mover class.
>
>For example, my mover class supports drag & drop, but if you use multiselect in listboxes, how that supposed to work with Drag&Drop? You multiselect the items in the listbox, then one wrong finger move and your selections are gone. Here the grid wit the logical field may be better solution.
>

Right. And this is how Cetin implemented it.

>What do you mean by auto-resizing exactly? There are many classes in Downloads section which automatically resize all controls on the form, why not use those?

I mean resize this particular container. Both listboxes should be centered in this container, have width = (width of container - width of buttons + some space)/2 and height = height of container - height of label - some space. Really simple code and it's already in _mover class of _FFC classes, but for some reason not in the class we have.

>
>Save and restore capability is problematic, not technically, but from the user point of view. Say, you have a lookup table with cities. You saved the state of your selections on Wednesday. On Thursday the lookup table was changed, some cities added, some dropped. You open your form on Friday. Now, how your saved state corresponds to the current data in the table? That was one of the reasons I dropped that functionality.

That's a correct point. In our case, though, the Lookups table are very rare updated, so this is almost 0.1% possibility in our case.

>
>You want the mover to work on any type of source, but for example moverbars in listboxes are allowed only if RowSourceType property is set to 0 (None) or 1 (Value). Moving the records in the grid may be done but will not look as natural as it is in listboxes.

It would require some really tricky code, which I think only you, Vlad or Cetin can write (not to mention other gurus, of course). But that's not too important.

>And the list goes on. Technically, most of these problems can be resolved, but the solution good for one group of users may be not be appreciated by another group.

That's true. I already abandon this idea due to its complexity. Now I'm working on simpler solution, but still find bunch of holes on the road bacause of imperfectness of our own framework :(