Re: [fpc-devel] Component FTag and Tag should be int64
Michael Van Canneyt escreveu: On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote: michael.vancann...@wisa.be escreveu: On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision. As I understand it , Andrew is talking about adding an additional field 'Data' of type pointer (or better would be TObject) which would exist next to the Tag field. For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Good. I've been waiting for some time: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg05886.html If it had not been for Delphi compatibility, you would have been waiting forever :-) So it seems that now it's time to add NativeInt type ;-) . BTW: i'm a fpc only guy and dont care keeping code compilable under Delphi but in the other side i do some porting of Delphi code. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote: michael.vancann...@wisa.be escreveu: On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision. As I understand it , Andrew is talking about adding an additional field 'Data' of type pointer (or better would be TObject) which would exist next to the Tag field. For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Good. I've been waiting for some time: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg05886.html If it had not been for Delphi compatibility, you would have been waiting forever :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
If you create the menuItem at runtime, you can always use a sub-class, create your own class TMyMenuItem, with a property and field to store the data.. > > That is what OO is for > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > > No, that's what the Tag feature is for, now that it done right...LOL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner mailto:andrew.t.brun...@gmail.com>> wrote: On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov mailto:max.vla...@gmail.com>> wrote: Andrew, Creating TList as a field for storing extra structures and objects and supporting extra data reference using Tag as an index never was a problem for me. Can you tell a single reason not to implement this approach by yourself? Moreover managing the destruction of objects in this case is much easier and straightforward. Other consideration, if something starts to depend on future decisions of other developers, isn't it easy to create a simple (very simple) workaround :) Max Vlasov In the specific problem I have, it is corellating TMenuItem with a particular data pointer object of TForm. Forms can close out of order and re-Index the List I have (as you stated). But there is no clean way for me to reference what was clicked on Sender... Tag or Data is the only clean solution here. Out of order, happening on application thread... Oh, and TMenuItems being created at runtime. This is about productivity. What must I create an additional list when I have Tag or Data. If you create the menuItem at runtime, you can always use a sub-class, create your own class TMyMenuItem, with a property and field to store the data.. That is what OO is for ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner wrote: > On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov wrote: > >> Andrew, >> Creating TList as a field for storing extra structures and objects and >> supporting extra data reference using Tag as an index never was a problem >> for me. Can you tell a single reason not to implement this approach by >> yourself? Moreover managing the destruction of objects in this case is much >> easier and straightforward. >> Other consideration, if something starts to depend on future decisions of >> other developers, isn't it easy to create a simple (very simple) workaround >> :) >> >> Max Vlasov >> >> >> > In the specific problem I have, it is corellating TMenuItem with a > particular data pointer object of TForm. Forms can close out of order and > re-Index the List I have (as you stated). But there is no clean way for me > to reference what was clicked on Sender... Tag or Data is the only clean > solution here. Out of order, happening on application thread... Oh, and > TMenuItems being created at runtime. This is about productivity. What must > I create an additional list when I have Tag or Data. > > > Things become a little more complex in this case, but just a little, [id:pointer] where id is autoincrement. You can have two synchronized lists (TList), one stored ids, another one - corresponding object. Or create a list with a record containing both. I'm from Turbo Pascal era so dynamic "array of" was a kind of novelty some time ago for me and I created an analogue. But this time [array of record id: integrer; ptr: pointer end;] is no longer a problem and you have privilege to use a language already containing such a great dynamic structure :) I also must say (probably others will confirm) that programming starting turbo pascal gave me once and for good the sense that the design-time objects and data are a great help, but just secondary help, everything solid comes from elsewhere. Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
michael.vancann...@wisa.be escreveu: On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision. As I understand it , Andrew is talking about adding an additional field 'Data' of type pointer (or better would be TObject) which would exist next to the Tag field. For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Good. I've been waiting for some time: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg05886.html Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov wrote: > Andrew, > Creating TList as a field for storing extra structures and objects and > supporting extra data reference using Tag as an index never was a problem > for me. Can you tell a single reason not to implement this approach by > yourself? Moreover managing the destruction of objects in this case is much > easier and straightforward. > Other consideration, if something starts to depend on future decisions of > other developers, isn't it easy to create a simple (very simple) workaround > :) > > Max Vlasov > > > In the specific problem I have, it is corellating TMenuItem with a particular data pointer object of TForm. Forms can close out of order and re-Index the List I have (as you stated). But there is no clean way for me to reference what was clicked on Sender... Tag or Data is the only clean solution here. Out of order, happening on application thread... Oh, and TMenuItems being created at runtime. This is about productivity. What must I create an additional list when I have Tag or Data. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 10:28 PM, Andrew Brunner wrote: > On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> They do the same as we: >> >> They introduced something like PtrInt (using of course a different name) >> and made tag equal to this type. >> >> Instead of biting the bullet and telling people to code properly. >> >> But like most companies, they are a bit of a prostitute in this regard. >> > > This is precisely why I asked to create a Data pointer so components can > assign extraneous data and associate it with said component. > > Andrew, Creating TList as a field for storing extra structures and objects and supporting extra data reference using Tag as an index never was a problem for me. Can you tell a single reason not to implement this approach by yourself? Moreover managing the destruction of objects in this case is much easier and straightforward. Other consideration, if something starts to depend on future decisions of other developers, isn't it easy to create a simple (very simple) workaround :) Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt wrote: > They do the same as we: > > They introduced something like PtrInt (using of course a different name) > and made tag equal to this type. > > Instead of biting the bullet and telling people to code properly. > > But like most companies, they are a bit of a prostitute in this regard. > This is precisely why I asked to create a Data pointer so components can assign extraneous data and associate it with said component. I see absolutely no legitimate argument as to why TComponent cannot have such a field. Memory is not a problem b/c if memory was a problem one would not be designing using the TComponent descendant. It would most likely be record or class. This is a legitimate design problem I have. Typcial Tcomponents only represent data. Just like a TListViewItem. Just because Delphi wants to use Tag and we want to use actual data pointer that does not invalidate the team's decision to not expand the FPC platform. But, I'm already starting to automate my own svn changes over here - I'll just have my own version :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, 23 Nov 2010, Sergei Gorelkin wrote: Andrew Brunner пишет: Ok. First off tag should be revised to match Delphi. Second. I need data property on Tcomponent I propose having an additional directive for this mechanism kind of like the option for using large strings. Components have data property. This way I can just get it into the Laz dialog. How about that? If we start adding new properties, directives, keywords etc on every such request, the end result will deserve only placing into trash. TComponent already allows a) Using Tag property to store indices into array or other container of data of any type; b) Using Components property to store any number of child components, which are owned, named, can notify and be notified of insertion and deletion. Regarding the Tag type, the fact we're tied up with that "Delphi compatibility" is quite unfortunate. I wonder how they are going to maintain compatibility between 32 and 64 bit versions. They do the same as we: They introduced something like PtrInt (using of course a different name) and made tag equal to this type. Instead of biting the bullet and telling people to code properly. But like most companies, they are a bit of a prostitute in this regard. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
Andrew Brunner пишет: Ok. First off tag should be revised to match Delphi. Second. I need data property on Tcomponent I propose having an additional directive for this mechanism kind of like the option for using large strings. Components have data property. This way I can just get it into the Laz dialog. How about that? If we start adding new properties, directives, keywords etc on every such request, the end result will deserve only placing into trash. TComponent already allows a) Using Tag property to store indices into array or other container of data of any type; b) Using Components property to store any number of child components, which are owned, named, can notify and be notified of insertion and deletion. Regarding the Tag type, the fact we're tied up with that "Delphi compatibility" is quite unfortunate. I wonder how they are going to maintain compatibility between 32 and 64 bit versions. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On 23-11-2010 17:19, michael.vancann...@wisa.be wrote: For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Michael. As I understand it, Andrew wants just the existing tag to be changed to 64 bit, Not an additional field. But PtrInt will do the job. The Data field suggests something like we have in KOL. But that is there for other reasons: no class ;-) Is anyone doing anything in converting KOL to 64 on their own? We would be interested and share our efforts, since there is a lot of demand from the community. Regards, Thaddy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
Ok. First off tag should be revised to match Delphi. Second. I need data property on Tcomponent I propose having an additional directive for this mechanism kind of like the option for using large strings. Components have data property. This way I can just get it into the Laz dialog. How about that? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote: Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision. As I understand it , Andrew is talking about adding an additional field 'Data' of type pointer (or better would be TObject) which would exist next to the Tag field. For Delphi compatibility reasons, the Tag type will be changed to PtrInt. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Nov 23, 2010, at 8:43 AM, Hans-Peter Diettrich > Components consume much space already, so what's the percentage that a 64 bit > type would add to every component, and to the app? And when the Tag type/sice > depends on the target, nothing will change unless for 64 bit targets. No. The sizeof(int64) is the same on all platforms/CPUs. Which is 8 bytes. 64bits*1byte/8bits. What data you fill that 8 bytes with is of no concern to the compiler. I is just bad practice to use it as anything other than whole numbers. QWord for unsigned. Int64 for signed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
Andrew Brunner schrieb: That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? First we have to agreee about the new type. Int64 could have been choosen already - by Delphi - when this were a reasonable decision. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
michael.vancann...@wisa.be schrieb: The task itself is easy. The consequences of this may not be so easy: TComponent is a basic class. Many many instances are created during the lifetime of an application. Adding a field that adds 4/8 bytes to such a class is something we're not eager to do, since it has potentially a large impact on the memory consumption of existing apps. Components consume much space already, so what's the percentage that a 64 bit type would add to every component, and to the app? And when the Tag type/sice depends on the target, nothing will change unless for 64 bit targets. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Tue, 23 Nov 2010, Andrew Brunner wrote: On Nov 23, 2010, at 2:27 AM, Max Vlasov wrote: On Mon, Nov 22, 2010 at 5:13 PM, wrote: We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit. Will it also create an additional confusion in design time? I mean, non-RAD compilers possibly only have compile-time context, while Lazarus has also design-time. One example, if the Tag is 64-bit and one set up the environment to cross-compile from 32-bit IDE to 64-bit, he or she even won't be able to change a 64-bit integer property in the designer. That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet??? The task itself is easy. The consequences of this may not be so easy: TComponent is a basic class. Many many instances are created during the lifetime of an application. Adding a field that adds 4/8 bytes to such a class is something we're not eager to do, since it has potentially a large impact on the memory consumption of existing apps. Everything has its reasons, as you can see. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Nov 23, 2010, at 2:27 AM, Max Vlasov wrote: > > > On Mon, Nov 22, 2010 at 5:13 PM, wrote: > > We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us > to follow suit. > > > > Will it also create an additional confusion in design time? I mean, non-RAD > compilers possibly only have compile-time context, while Lazarus has also > design-time. One example, if the Tag is 64-bit and one set up the environment > to cross-compile from 32-bit IDE to 64-bit, he or she even won't be able to > change a 64-bit integer property in the designer. That would not be an issue as Int64 is available under all flavors of FPC. I don't see the hold up in adding a patch for Data field. There is just one unit to change. What makes this so complicated that it hasn't be accomplished yet???___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Mon, Nov 22, 2010 at 5:13 PM, wrote: > > We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces > us to follow suit. > > Will it also create an additional confusion in design time? I mean, non-RAD compilers possibly only have compile-time context, while Lazarus has also design-time. One example, if the Tag is 64-bit and one set up the environment to cross-compile from 32-bit IDE to 64-bit, he or she even won't be able to change a 64-bit integer property in the designer. And also speaking of following/not following Delphi, I think Lazarus has two things to have courage not to follow the trend: - dfm and lfm is not easily interchangeable, so if Lazarus is not going with Delphi with the tag size, there's always could be a warning (highlighting) pointing out to an exceeded Tag value. - the compiler for a long time had pointer conversion not portable hint/warning so no matter how big Tag is, writing SomeMyAddr:=pointer(Obj.Tag) already warns the developer. Hmm, also a little off-topic analogy, AMD was the second until they were first with 64-bit processors. Intel just had to follow. Project this to Pascal ;-) Max Vlasov ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
michael.vancann...@wisa.be schrieb: The logic is that it is bad programming to use an integer to store a pointer. That's why handles are used for that purpose, and on a 64 bit system handles can have 64 bits as well. Handles are equally bad. They are *not* pointers. A user cannot know, and should not care, what hides behind a handle. You should store a pointer in a variable of pointer type, period. See lParam in messages... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Mon, 22 Nov 2010, Hans-Peter Diettrich wrote: michael.vancann...@wisa.be schrieb: I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. ___ The logic is that it is bad programming to use an integer to store a pointer. That's why handles are used for that purpose, and on a 64 bit system handles can have 64 bits as well. Handles are equally bad. They are *not* pointers. You should store a pointer in a variable of pointer type, period. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
michael.vancann...@wisa.be schrieb: I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. ___ The logic is that it is bad programming to use an integer to store a pointer. That's why handles are used for that purpose, and on a 64 bit system handles can have 64 bits as well. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Mon, 22 Nov 2010, Andrew Brunner wrote: On Nov 22, 2010, at 9:13 AM, michael.vancann...@wisa.be wrote The logic is that it is bad programming to use an integer to store a pointer. And we don't want to encourage bad programming. Yes, I know it's easy, and yes I know it's common practice. Neither make it right to do so. We'll fix the issue I was going to disagree with that statement. But after considering it some what then would be the likelihood of getting TComponent to have a Data property of pointer??? That would be my preferred (and already proposed) solution. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
- "michael vancanneyt" schreef: > On Mon, 22 Nov 2010, Andrew Brunner wrote: > > > I was looking at the code for Tag property in classes unit and > noticed I can't safely use Tag to keep runtime pointers (at least on a > 64 bit compile). What is the likelihood of getting tags changed to > support universal access under 64/32 bit compiles? > > > > What is the logic behind the shortfall? I suspect just legacy and it > could be easily fixed. > ___ > > The logic is that it is bad programming to use an integer to store a > pointer. > And we don't want to encourage bad programming. > > Yes, I know it's easy, and yes I know it's common practice. > Neither make it right to do so. > +64 Never EVER fall into the VB bullshit trap that is the Tag property. Related to that matter, Windows/delphi has a few of these "Data pointers", especially the stuff that is lower-level and is used to invoke the winapi with as a parameter (callbacks anyone?). Always try to stay clear of it as much as possible, because it does encourage and even invite bad programming. > We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - > forces us > to follow suit. sad to read this part though... kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Nov 22, 2010, at 9:13 AM, michael.vancann...@wisa.be wrote > >> > The logic is that it is bad programming to use an integer to store a pointer. > And we don't want to encourage bad programming. > > Yes, I know it's easy, and yes I know it's common practice. Neither make it > right to do so. > > We'll fix the issue I was going to disagree with that statement. But after considering it some what then would be the likelihood of getting TComponent to have a Data property of pointer???___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
On Mon, 22 Nov 2010, Andrew Brunner wrote: I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. ___ The logic is that it is bad programming to use an integer to store a pointer. And we don't want to encourage bad programming. Yes, I know it's easy, and yes I know it's common practice. Neither make it right to do so. We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Component FTag and Tag should be int64
I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
