Le 03/04/2014 22:55, MartinW a écrit :
Goubier Thierry wrote
Another approach, that I would use, is to put more complex objects
inside the lists. Thoses objects would know how to get added / removed
from their respective collections, and then I would propagate collection
changes to the ListModel instances.
That sounded promising. I made a Collectible class. It's instances know how
to add themselves to a collection (i'm not sure if that's a good idea, but
as experiment..)
The problem is, i never get to these objects in my acceptDropBlock. In
list1 acceptDropBlock: [ :transfer :event :source :receiver :index |
transfer passenger do: [:element | element addSelfToCollection:
collection1] ].
the element is only a ByteString - the name of my Collectible object. :(
I believe what is happening is that ListModel and the widget above
convert your Collectible instance into a string to display it; and then
the drag and drop code forget to get the model object behind the
displayed string (i.e. the drag and drop code expect all items to be
morphs with all sort of complex stuff).
By the way, any chance of having your code as an example for Spec? I
went through the spec documentation and I couldn't see anything similar,
and, from our difficulties to get that to work, I would guess a bit of
work on Spec drag and drop support could be a good thing.
Are there other possibilities if i do not use Spec?
Yes. Drag and drop code in Morphic is fairly similar. The Morphic code
for opening windows is certainly longer, however.
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
