Am Mittwoch, 6. September 2006 11:05 schrieb Michael Van Canneyt: > On Wed, 6 Sep 2006, Ale Katona wrote: > > The problem here is that if you introduce a changing type to Tag, > > you're going to break streaming of the components between various > > platforms. However I think simplest would be to simply make the tag > > something huge for years to come, like Int64. > > > > The idea with hidden union is nice tho. But you'll need to know how > > to stream it precisely and there's also endianness to take care of > > then. > > I've been following the discussion, and the tag property will remain > what it is: a 32-bit integer. It was introduced by Delphi to mimic > the Tag property which exists in VB, to allow it to be used in case > statements. Changing it will probably cause more problems than it > will solve. > > In casu: > > Typecasting 'Tag' to a pointer is a non-portable, ugly hack and we > should not encourage such hacks. > > If you want to store objects, use a TCollection, and store > TCollectionItem.ID in the component tag. ID is a unique identifier, > even when elements are added and removed from the collection. > > Slightly more work, but clean and portable. > > Michael.
In many situations, the collection would be overkill, so I'd also opt for the new public property "UserData : pointer" or better "TagPtr : pointer". This would make it harder to create code, that also compiles with delphi, but that doesn't bother me ;-) Anyway, if one needs to compile with delphi, one could continue to use pointer(tag), as delphi is 32-bit only anyway ... This way the user has the choice to write code that compiles with fpc32+delphi or fpc32+fpc64 regards Burkhard _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
