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
