Hi, I am making a small tabbed notepad program and I not sure were to store the filename of an opened file. as the TTabsheet has a property for tag but can only store a integer.
so I was wondering how is the best way of doing it. I thought of using a string list to keep each of the opened filenames in the list but I don't know if this is effective way of doing it.
I did have the idea of maybe turning a string into a pointer I done this is C++ but not sure how to do it in lazarus then store that pointer in the tag and then to get the string I need a way to convert the pointer back to a string.
QuoteI did have the idea of maybe turning a string into a pointer I done this is C++ but not sure how to do it in lazarus then store that pointer in the tag and then to get the string I need a way to convert the pointer back to a string.
That sort of thing is a bad idea in C++ and a worse idea in a well-designed language :-)
Seriously: neither necessary nor wise. At the application level I use an explicit pointer every five years or so.
I did sort of find a way around it, what I did was store the filename in the TabSheets hint property seems to work. thanks again
In fact that is the purpose of the Tag property, that's why it's a PtrInt after all.
In fact that is the purpose of the Tag property, that's why it's a PtrInt after all.
Didn't used to be: Delphi defined it as a straight integer of indeterminate size. And not even as an unsigned, which would have been reasonable if they anticipated people putting pointers in that field.
Tag has no predefined meaning. The Tag property can store any additional integer value for the convenience of developers. Often, Tag stores a pointer. A Tag value can be typecast to the appropriate pointer type. Notice that on 64-bit platforms, all pointer types are 8 bytes in size, while on 32-bit platforms, pointer types are 4 bytes. These pointer sizes correspond to sizes of NativeInt integral values on 64-bit and 32-bit platforms.
Which I suppose raises the interesting question of what the lowest-overhead object is which can store a single string.
Which I suppose raises the interesting question of what the lowest-overhead object is which can store a single string.
Depends: if you know it's less than 4 characters it would be a UInt32 or Int32 (e.g. for ACPI device names) (in MacPas mode FPC supports assigning 4 character strings to 32-bit ordinals ;) ), otherwise it would probably be PChar, followed by ShortString (with the obvious restriction in length), then a dynamic array of Char and then AnsiString.
Which I suppose raises the interesting question of what the lowest-overhead object is which can store a single string.
Depends: if you know it's less than 4 characters it would be a UInt32 or Int32 (e.g. for ACPI device names) (in MacPas mode FPC supports assigning 4 character strings to 32-bit ordinals ;) ), otherwise it would probably be PChar, followed by ShortString (with the obvious restriction in length), then a dynamic array of Char and then AnsiString.
Thanks for that but I did specifically say object, i.e. something whose type/class can be tested at runtime which I presume isn't possible for a dynamic array or an ansistring.
Superficially one would assume that a StringList with a single entry is overkill, but that depends on how much per-instance space is allocated and on whether anything time-consuming is done during creation.
“Object” is a rather overloaded world in the Pascal world. Aside from an object instance it might mean TP-style object or - as I had interpreted it - simply a collective name for something that represents something.
Please note that you can't reliably detect however the case that the value is not 0, but also not a valid object (e.g. store 1 into the Tag and try to handle it as a TObject-descendant).
If you want to go with a TObject-descendant then a direct descendant of TObject with a String field is the best bet (and some do in fact use the Tag property like this)
QuotePlease note that you can't reliably detect however the case that the value is not 0, but also not a valid object (e.g. store 1 into the Tag and try to handle it as a TObject-descendant).
Although the misalignment should be a strong hint. That's actually how classic Smalltalk distinguished between objects (their term :-) and integers: whether the LSB was set; and I think I've noticed hardware support in recent x86 to specifically make that check.
In principle nothing forbids the heap manager to allocate its memory 1-Byte aligned and thus you could have a class instance that starts at an odd address. And even then you'd only detect this every second value. ;)