I'm struggling with interfaces in Delphi. This question might be trivial, but I am new to Delphi, so please excuse.
I have a TreeView with customized nodes, which hold an interface to an object (essentially, just like it is proposed here: Storing interface pointer inside tree view nodes).
The problem is, once I delete a node (in order to redraw the treeview) and set the interface variable to nil (freeing won't do with interfaces for some reason I haven't fully understood), the weirdest thing happens:
In my object, which contains a list, an integer and a string variable, the string and list will be set empty, while the integer remains the same.
I can't explain this. Does anybody know a workaround, or the possible reason for this behavior? BTW, I am using Delphi 10.2 Tokyo.
Here's my quite unspectacular destroy method:
myNode.destroy;
begin
intf:= nil;// intf holds the interface to the object
end;
Edit: this is a simplified version of my code:
The object I'm referring to: (I have several similar classes which look like obj but are slightly different and I don't know which one will be stored in the interface, but all share these variables)
Obj = class(InterfacedObject, IMyinterface)
count: integer; //this remains the same
children: array of ChildObj; //this will be emptied
name: string; //this will be set to ''
procedure addChild;
procedure IMyInterface.add = addChild;
end;
My customized treeNode:
MyNode = class(TTreeNode)
Intf: IMyinterface;
destructor destroy; override;
end;
Inside my class manages the TreeView:
MyForm.ReloadTree;
begin
if myTreeView.Items.Count > 0 then
begin
myTreeView.Items.Clear;
end
for I:= 0 to RootObj.Count-1 do
begin
myTreeView.Items.AddChild(MyTreeview.Items[0], RootObj.Children[i].name);
(myTreeView.Items[0][i] as MyNode).Intf := Intf(RootObj.Children[i]);
//I will proceed iterating over all children and their children, doing
//the same process, a level higher in the treeView
//...
end;
end;
in my object, which contains a list, an integer and a string variable, the string and list will be set empty, while the integer remains the same.
This is perfectly normal behavior. Strings and interfaces are compiler-managed types. Integers are not. When an object is destructed, compiler-managed data members are automatically deallocated as needed, which in the case of strings and interfaces involves nil'ing the pointers to their referenced data. The containing object itself is not zeroed out completely, so non-managed types, like integers, are not overwritten in memory.
Now, that being said, I see some bugs in your ReloadTree() procedure.
Your for loop is exceeding the upper bound of the RootObj.Children[] list.
When calling AddChild(), the second parameter is a string. You are passing RootObj.Children[i] in that parameter. But, in the next statement, you are type-casting the same RootObj.Children[i] value to an interface when assigning the MyNode.Intf field. A string is not an interface. So, what exactly does RootObj.Children[] contain - strings or interfaces?
When assigning the MyNode.Intf field, you are always accessing the first node in the TreeView, instead of the newly added node.
Related
How can I use record in TDictionary?
TMyRec = record
a: Integer;
b: Integer;
end;
...
dictionary = TDictionary<String, TMyRec>.create();
...
dictionary[key].a := 30;<<<
Here the compiler gives an error: "Left side cannot be assigned to". How can I solve this problem without creating a separate function for writing myFunc(a, b: Integer): TMyRec?
dictionary[key] returns a copy of the record held by the dictionary. The compiler prevents you from modifying that because it would serve no purpose.
As an aside, older versions of the program would accept your code and it was very confusing that the modification to the record would be lost. You'd make an assignment but nothing visible changed because what you assigned was a nameless local variable.
Clearly you intend to modify the record held in the collection. In order to do that you need to assign the entire record. Read the record from the collection into a local variable. Modify the local variable. Write the updated value back to the collection. Like so:
var
rec: TMyRec;
...
rec := dictionary[key];
rec.a := 30;
dictionary[key] := rec;
One of the frustrating aspects of this is that the code needs to perform two dictionary lookups, even though we know that the second one will find the same record as the first one. Not even the mighty Spring4d dictionary can do this with a single lookup.
David Heffernans answer is what you're after, but I would like to offer an additional warning. Records can have properties just like classes, with getters and setters, and if your record has such properties your code will compile, but it will still not change the actual record value.
TMyRec = record
private
FA : integer;
procedure SetA(const Value: integer);
function GetA : integer;
public
{ Warning: When used on result from dictionary lookup, only the COPY will be
altered, not the actual record in the dictionary! }
property A : integer read GetA write SetA;
end;
A very simple workaround is to use the List property of the record.
You can say:
dictionary.list[key].a := 30;
This will access the dynamic array that backs up the TList via the List property. The compiler already supports direct access to a dynamic array.
If you can login to quality.embarcadero.com, you can see the full discussion of this issue raised as: RSP-23136: We should be able to assign a value to one element in a list of records - posted Dec 18, 2018 and resolved Nov 21, 2019.
The issue was closed with the comment:
"This works as expected. Alternative coding style was provided."
I have a class that looks like this:
type
TLogin = class(TThread)
private
//variables...
protected
procedure Execute; override;
public
constructor Create(testo: TLabel; splash: TRectangle; username: string; labels: LabelArray);
end;
I know that a constructor can take an endless number or parameters but I always prefer to have a little amount and I guess that 4 is the max. I have managed to reduce the numbers of parameters using a LabelArray.
type
LabelArray = array of TLabel;
It has a length of 15-22 (decided at runtime) and I was wondering if this code is correct or not (look at the var):
constructor Create(testo: TLabel; splash: TRectangle; username: string; var labels: LabelArray);
Does this makes sense? Of course the code compiles but I am not sure if the array is already passed by reference. I don't want to make a copy because that would be useless; I am going to change the text of those labels inside my array so I'd prefer a pass-by-reference.
This is a class that runs in a thread separated from the GUI so I'm calling a Queue at a certain point to update the labels' text of the main form. It would be
Queue(nil, procedure
begin
FLabelArray[0].Text := '...';
FLabelArray[1].Text := '...'; //and so on
end);
For this reason I think that a copy wouldn't be useful.
Delphi dynamic arrays are reference types. Passing the array with var doesn't accomplish anything because your constructor isn't actually assigning a new value to the labels parameter. There's no method of passing a dynamic array that would cause a copy to be created.
It's sufficient for your constructor to assign the labels parameter to the FLabelArray field with a simple assignment statement:
FLabelArray := labels;
That increases the array's reference count, so it will remain a valid array for the lifetime of the thread object you've just constructed.
Dynamic arrays are reference counted, so it doesn't really matter in this situation if you pass it by value or by reference. And even if you were passing around copies, the array holds object pointers, which are lightweight to make copies of. Your Queue() calls would still be operating on the original TLabel objects.
I am using delphi XE5.
This a resume of my code, Next code works, but there have to be something in my code that destroy normal behaviour:
unit Class1;
type
TClass1 = class
private
FDic:TDictionary<String,String>.Create;
public
constructor create;
procedure insertValue(key,value:String);
end;
implementation
constructor TClass1.create;
begin
FDic:=TDictionary<String,String>.Create;
end;
procedure insertValue(key,value:String);
begin
if(FDic.ContainsKey(key))then
FDic[key] := value
else
begin
FDic.Add(key,value);
end;
end.
And now another unit:
unit Class2;
type
uses Class2;
TClass1 = class
public
class2 :TClass2;
TS: TStringList;
procedure DoSomething;
end;
implementation
procedure TClass1.DoSomething;
var
i: Integer;
c,test: TClass1;
begin
c := TClass1.create;
c.insertValue('height','.34cm');
c.insertValue('width','22cm');
c.insertValue('radio','2cm');
TS.AddObject('square',c);
c := TClass1.create;
c.insertValue('height','.88cm');
c.insertValue('width','11cm');
c.insertValue('top','12cm');
TS.AddObject('circle',c);
test := TS.Objects[0] as TClass1;//test.FDic height should be .34cm but gets the value of the last object create, the same for width an common keys.
//here when I look for the values of FDic test.FDic.Items['height'] the value is .88cm instead of .34cm, each time the values of any element of the Dictionary is replace with the previous of the last object created. And the memory address is the same. Why don't create a new memory address for any new element if it is a different object.
That is a resume of my code, I can put all my code because is too big, but I would like to know where I can search to resolve this problem. I am not is not easy, maybe I am not the only one with that problema, maybe some class in the uses, class variables, there is something that causes a memory problema in that dictionary, but no way to find it.
It's a little hard to be sure of the problem because you posted code that does not compile. For future reference, please don't do that. It's good to cut down the code to a small size, but you should then make it into a small console application that compiles and runs and demonstrates the fault. In spite of this, I think that I can see where the problem is.
You are creating objects and then adding them to a string list with
TS.AddObject(...);
But then you never free those objects. That, I guess, is the source of the leak. You can deal with this by setting the OwnsObjects property of the string list to True.
Specifies whether the string list owns the objects it contains.
The OwnsObjects property specifies whether the string list owns the
stored objects or not. If the OwnsObjects property is set to True,
then the Destroy destructor will free up the memory allocated for
those objects.
That I think will explain the leaks. The other part of your question is why index 0 contains the item that you added second. The only explanation for that, given the code in the question, is that your string list has the Sorted property set to True.
Again, I'm inferring this with a little intuition, but if you have only posted a complete program that compiled and run then your question could have been answered with complete certainty.
I do wonder whether or not a string list is the correct class to be using here. Perhaps you would be better with TObjectDictionary<string, TClass1>. You would create it like this:
dict := TObjectDictionary<string, TClass1>.Create([doOwnsValues]);
The use of doOwnsValues tells the dictionary that it is take assume ownership of the objects that you add as values and destroy them when they are removed from the dictionary, or when the dictionary is destroyed.
Note also that your insertValue method can be implemented in a far simpler way using the AddOrSetValue method.
Delphi 2007, moving to Delphi XE over the next year.
Our product makes extensive use of a third-party component. We don't use the component directly, but instead use a custom descendant of it, to which we've added quite a lot of extra behavior (the custom descendant component was developed several years ago by developers who have since have retired).
In the source unit of the third-party Parent class, some enumerated types are declared, which control various operations of the component:
TSpecialKind = (skAlpha, skBeta, skGamma);
TSpecialKinds = set of TSpecialKind;
In our descendant class, we want to add new behavior, which would require expanding the selection of enumerated types. Essentially, we want this:
TSpecialKind = (skAlpha, skBeta, skGamma, skDelta, skEpsilon);
TSpecialKinds = set of TSpecialKind;
Obviously, we want to avoid editing the third-party code. Is it valid to simply redeclare the enumerated type, repeating the original values and adding our new ones, in our own descendent unit? Will it have any effect on existing code?
Edit:
Example scenario to (hopefully) clarify. Say you've got a (parent) component for ordering vehicle parts. The parent unit has an enumerated type Tvkind for vehicle kind, with values vkCar and vkCycle defined. These values are used, among other things, to indicate how many wheels the vehicle has, 4 or 2.
Now, in your descendent component, you want to be able to handle 3-wheeled vehicles as well. Extending the Tvkind enumerated type to include a new value vkTrike seems like the obvious approach. But what if you don't have access to or don't want to modify the parent component code?
Inheritance for enumeration types doesn't work the same way it works for Classes because code makes assumptions about enumerations that it would never make about a class. For example, given your original enumeration (the TSpecialKind), the third party component likely includes code like this:
var Something: TSpecialKind;
[...]
case Something of
skAlpha: ;
skBeta: ;
skGamma: ;
end;
Even if you could cast something that's not part of that enumeration to the TSpecialKind type, the result of that code above would be undefined (and definitively not good!)
Enumerations might be used in one other way, and if the third party component only uses it that way, then you might be able to do some "wizardry", but I don't recommend it. If the original TSpecialKind is only used through it's TSpecialKinds set type, and then it's only used like this:
if skBeta in VarOfTypeSpecialKinds then
begin
...
end;
(continued) then you could introduce a new type that enumerates all of the original values, in the same order, with the same value. If after you do that SizeOf(TSpecialKind) equals SizeOf(TNewType) then you can hard-cast the new set value to the old value and the old code would work the same. But frankly this is hacky, to many conditions for it to work properly, too fragile. The better solution would be to use a new enumeration type that's only used in your descendant component:
type TExtraSpecialKind = (skDelta, skEpsilon);
TExtraSpecialKinds = set of TExtraSpecialKind;
You'll probably have this set published in a different property; The solution is clean, will mix well with the descendant code and can be used cleanly too. Example:
if (skAlpha in SpecialKind) or (skDelta in ExtraSpecialKind) then
begin
// Do extra-sepcial mixed stuff here.
end;
I don't believe that you can reasonably expect to make the change that you want without modifying the original component.
Let's take your vehicle kind example and delve a bit deeper. I expect that the original component will have code like this:
case Kind of
vkCar:
CarMethod;
vkCycle:
CycleMethod;
end;
Now, suppose you introduce an enumerated type with an extra enumeration
TExtendedVehicleKind = (vkCar, vkCycle, vkTrike);
If the case statement above runs, with ExtendedKind equal to vkTrike, no method will be called.
Now, perhaps the behaviour that you want from the original control can be achieved by setting Kind to vkCar or vkCycle when ExtendedKind is vkTrike. But that seems unlikely to me. Only you can know for sure, because only you have the code, and know what your actual problem is.
Been in the "need to extended the enumerated type of a property".
Quick First Suggestion. Add your enumeration, as a new property wrapper to the existing property:
Potential Parent class code:
unit AcmeMachines;
interface
type
FoodCanEnum =
(
None,
Fish,
Bird,
Beef
);
AcmeCanAutoOpenMachineClass= class (object)
protected
{ protected declarations }
F_FoodCanEnum: FoodCanEnum;
function getFoodEnumProperty: FoodCanEnum;
procedure setFoodEnumProperty(const AValue: FoodCanEnum);
public
{ public declarations }
property FoodEnumProperty
read getFoodEnumProperty write setFoodEnumProperty;
end;
implementation
function AcmeCanAutoOpenMachineClass.getMyFoodEnumProperty: FoodCanEnum;
begin
Result := F_FoodCanEnum;
end;
procedure AcmeCanAutoOpenMachineClass.setMyFoodEnumProperty
(const AValue: CatFoodCanEnum);
begin
FoodEnumProperty:= AValue;
// do some specific business logic
end;
end;
Descendant Class code:
unit UmbrellaMachines;
interface
uses AcmeMachines;
type
CatFoodCanEnum =
(
None, <--- matches "AcmeMachines.None"
Fish, <--- matches "AcmeMachines.Fish"
Bird, <--- matches "AcmeMachines.Bird"
Beef, <--- matches "AcmeMachines.Beef"
Tuna,
Chicken
);
UmbrellaCanAutoOpenMachineClass = class (AcmeCanAutoOpenMachineClass)
protected
{ protected declarations }
F_CatFoodCanEnum: CatFoodCanEnum;
function getMyFoodEnumProperty: CatFoodCanEnum;
procedure setMyFoodEnumProperty(const AValue: CatFoodCanEnum);
public
{ public declarations }
// new property, "wraps" existing property
property MyFoodEnumProperty
read getMyFoodEnumProperty write setMyFoodEnumProperty;
end;
implementation
function UmbrellaCanAutoOpenMachineClass.getMyFoodEnumProperty: CatFoodCanEnum;
begin
// wrap existing "FoodEnumProperty" property, using an existing value as dummy
Result := F_CatFoodCanEnum;
end;
procedure UmbrellaCanAutoOpenMachineClass.setMyFoodEnumProperty
(const AValue: CatFoodCanEnum);
begin
// wrap existing property, using an existing value as dummy
// may be another value if necessary
AcmeCanAutoOpenMachineClass.ExistingFoodEnumProperty := AcmeMachines.None;
F_CatFoodCanEnum := AValue;
// add extended business logic for this class instances
end;
end;
Extra.
If possible, always add a "null" or "dummy" value to your own enumerations, usually, the first value:
type
CatFoodCanEnum =
(
None, // <--- these one
Tuna,
Chicken,
Beef
);
Cheers.
I think that C++ supports something on the lines of :
Object objects[100];
This would instantiate a 100 objects, right? Is it possible to do this in Delphi (specifically 2007)? Something other than:
for i:=0 to 99 do
currentObject = TObject.Create;
or using the Allocate function, with a passed size value a hundred times the TObject size, because that just allocates memory, it doesn't actually divide the memory and 'give' it to the objects.
If my assumption that the c++ instantiation is instant rather than under-the-hood-iterative, I apologize.
What you are looking for is impossible because
Delphi does not support static (stack allocated) objects.
Delphi objects do not have default constructors that can be automatically invoked by compiler.
So that is not a lack of 'sugar syntax'.
For the sake of complete disclosure:
Delphi also supports legacy 'old object model' (Turbo Pascal object model) which allows statically allocated objects;
Dynamic object allocation itself does not prevent automatic object instantiation syntax, but makes such a syntax undesirable;
Automatic object instantiation syntax is impossible because Delphi does not have default constructors: Delphi compiler never instantiate objects implicitly because it does not know what constructor to call.
While you can't do what you want using objects, if your objects are relatively simple, you may be able to get what you want by using an array of records.
Records in Delphi can have properties (including setters and getters), and class and instance methods. They are created automatically when declared, so declaring an array of them will create them all without iterating.
For more info: http://docwiki.embarcadero.com/RADStudio/XE3/en/Structured_Types#Records_.28advanced.29.
(I'm not sure when the new functionality was added to Delphi, it may well be after the 2007 version).
I don't know of any non-hacky way to do this besides iterating:
var
MyObjects: array[0..99] of TMyObject;
i: Integer;
begin
for i := 0 to 99 do
MyObjects[i] := TMyObject.Create;
end;
That declaration wouldn't create 100 objects, it would just give you an array of 100 object references that point to nothing useful.
Creating an object is a two step process. The first step is allocating memory (which your code also doesn't), the second step is calling the constructor (Create method) to initialize that memory, create additional objects, etc, etc.
The allocation part can be done without the loop, but the constructor needs to be called to intialize each instance.
Many VCL classes don't have an additional constructor. They just have the empty constructor that does nothing. In that case, there is no need to call it.
For instance, to fetch an array of stringlists, you can use the following code, adjusted from this example:
type
TStringListArray = array of TStringList;v
var
Instances: array of Byte;
function GetStringLists(Number: Integer): TStringListArray;
var
i: Integer;
begin
// Allocate instance memory for all of them
SetLength(Instances, Number * TStringList.InstanceSize);
// Zero the memory.
FillChar(Instances[0], Length(Instances), 0);
// Allocate array for object references.
SetLength(Result, Number);
for i := 0 to High(Result) do
begin
// Store object reference.
Result[i] := #Instances[i * TStringList.InstanceSize];
// Set the right class.
PPointer(Result[i])^ := TStringList;
// Call the constructor.
Result[i].Create;
end;
end;
And to get an array of 100 stringlists:
var
x: TStringListArray;
begin
x := GetStringLists(100);
So while this procedure may save you a neglectable amount of time, and may theoretically be more memory-efficient (less fragmentation), you will still need the loop. No easy way out.
It is somewhat possible in Delphi (but is not very practical in a Delphi environment, unless you are writing a custom memory manager). Creating an object instance is a two-step process - allocating memory for the object, and constructing the object's members inside of that memory. There is nothing requiring the memory of a given object to be allocated individually. You can allocate a larger block of memory and construct multiple objects inside of that block, taking advantage of a feature of Delphi that calls a constructor like a normal method if it is called from an instance variable instead of a class type, eg:
var
objects: array of Byte;
obj: TSomeClass;
begin
SetLength(objects, 100 * TSomeClass.InstanceSize);
FillChar(objects[0], 0, Length(objects));
for i := 0 to 99 do
begin
obj := TSomeClass.InitInstance(#objects[i * TSomeClass.InstanceSize]));
obj.Create;
end;
...
for i := 0 to 99 do
begin
obj := TSomeClass(#objects[i * TSomeClass.InstanceSize]);
obj.CleanupInstance;
end;
SetLength(objects, 0);
end;
This is not much different than what C++ does behind the scenes when declaring an array of object instances, only C++ supports declaring the array statically and it will call the constructors and destructors automatically, whereas Delphi does not support that.
There are a number of third-party implementations that allow you to allocate objects on the stack or in user-defined buffers, such as:
Objects on the Stack: A Delphi Relic
Allocate objects on stack, at specified memory address, or through any memory manager
Just to name a couple.