I am sure the Slug and/or Trevor will chime in here.. good points.... the redirection might have an impact on the speed in this case... Maybe a special 'data grid fixer' handler....
On 24 January 2012 14:06, Bob Sneidar <b...@twft.com> wrote: > It would work for user created objects, except how do you get datagrids to > do this? All kinds of things in the datagrid are linked by long ID's to > their behaviors by the engine. I'd be nervous about going into any > functioning datagrid and trying to update all the object behavior > references, and then when the datagrid creates new objects, unless you > modify the datagrid library, it is also going to assign long ID's to those. > > This does bring up an interesting point though. I think the datagrid > library could be updated in such a way that the objects it creates could be > persistent, that is, given the same size datagrid, same rows and columns, > the objects would not be deleted or recreated simply because the data > changed. It would also address the issue of how to deal with adding data > below the last data in the datagrid. If the cells were already there you > would just double click on one to edit it. > > It would be quite an undertaking, but it is my opinion that the datagrid > should have been designed this way to begin with. It solves a lot of > problems we run into now, and we have discussed previously what happens in > an app after a number of years of heavy use if you run out of ID's. It's > hardly likely I suppose, but it's a possibility. Just thinking out loud > here. > > Bob > > > On Jan 24, 2012, at 1:28 PM, stephen barncard wrote: > > > uniquely naming all objects and using 'get the id of object <name>' > > instead of using any IDs at all would seem to solve this problem... > > > > of course would have to be a convention when starting a project. > > > > why wouldn't this work? > > > > On 24 January 2012 13:20, Bob Sneidar <b...@twft.com> wrote: > > > >> Yes the more I think about it, the more tedious it becomes. It seems the > >> only way to do multiuser dev is to have the source stack available to a > >> kind of checkout engine. A dev would have to check out an object at > which > >> point it would be unavailable to any other user. And you would have to > have > >> a running copy that was the exact replica of the original including > ID's. > >> Not sure how to do that. > >> > >> Way back when some made the argument that it was a bad idea to use ID's > as > >> references to objects. Now it seems we understand much more how true > that > >> is. We are beyond the point of know return now. :-) > >> > >> Bob > >> > >> > >> On Jan 24, 2012, at 11:59 AM, Pete wrote: > >> > >>> Bob, > >>> I think you'd have to find some way to preserve object IDs or a lot of > >>> stuff would break. Datagrids, for example, store the row template as a > >>> long id. And, as you pointed out, behaviors. > >> > >> > >> _______________________________________________ > >> use-livecode mailing list > >> use-livecode@lists.runrev.com > >> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > > > > > > > > -- > > > > > > > > Stephen Barncard > > San Francisco Ca. USA > > > > more about sqb <http://www.google.com/profiles/sbarncar> > > _______________________________________________ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- Stephen Barncard San Francisco Ca. USA more about sqb <http://www.google.com/profiles/sbarncar> _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
