That doesn't seem right. elm_gengrid_item_data_set effectively calls elm_widget_item_data_set, which sets the data in Elm_Widget_Item->data, whereas the data that is passed to all the append|prepend functions is stored in Elm_Gengrid_Item->func.data. To me, they look like totally different places, unless I'm missing something.
On Sun, Nov 14, 2010 at 5:11 AM, Carsten Haitzler <ras...@rasterman.com>wrote: > On Sun, 14 Nov 2010 04:34:27 +0200 Viktor Kojouharov < > vkojouha...@gmail.com> > said: > > no - it's the one and the same data - if u set it (change it later for that > item) then the new data pointer you set will be passed to the del and other > class calls. > > > you get the item that that was passed when item_append|prepend was > called. > > But you can also call elm_gengrid_item_data_set, and if I red the code > > correctly, that doesn't touch the previous data, but sets a whole new > one. > > And this is the one that you cannot get during the deletion of the item. > > > > On Sun, Nov 14, 2010 at 4:13 AM, Carsten Haitzler <ras...@rasterman.com > >wrote: > > > > > On Sat, 13 Nov 2010 18:54:38 +0200 Viktor Kojouharov < > > > vkojouha...@gmail.com> > > > said: > > > > > > because it gets the item DATA that is set (the app-side data) for it to > > > clean > > > up/delete. genlist/grid will delete the object that is the item itself. > so > > > you > > > don't get it. if you want to clean up something in the object of the > item > > > itself - you can register and evas del callback on it to clean up > attached > > > keys. as genlist/grid add and delete these list item objects > dynamically. > > > the > > > evas object you are passed is the genlist itself. you know what genlist > it > > > was > > > your data belonged to - you may or may not use that. the genlist/grid > items > > > though - i fail to see why you need it? you got the pointer you passed > in > > > on > > > create (userdata) as *data in the del cb for you to clean up. you have > the > > > genlist/grid pointer itself in case you need it. > > > > > > > Why doesn't that function receive the actual item object as a > parameter? > > > > The object itself can hold user data, which might need cleaning when > the > > > > item is deleted. From that function however, there's no way to clear > that > > > > data, since all you get is an evas_object (whose usefulness escapes > me). > > > May > > > > I propose that we also pass the gen*_item as a third parameter to the > del > > > > functions? > > > > > > > > ------------------------------------------------------------------------------ > > > > Centralized Desktop Delivery: Dell and VMware Reference Architecture > > > > Simplifying enterprise desktop deployment and management using > > > > Dell EqualLogic storage and VMware View: A highly scalable, > end-to-end > > > > client virtualization framework. Read more! > > > > http://p.sf.net/sfu/dell-eql-dev2dev > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
