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