Please enable JavaScript to view this site.

KOL/MCK - User Guide

 

pointing-up-finger

I'll make a point here: unlike classes, here you have to free all the resources belonging to the object yourself. Namely: all fields that are objects and created for the lifetime of this particular object (call of the Free method). All dynamic chunks of memory allocated by AllocMemory or GetMem (call to the FreeMem function). All dynamic arrays (call SetLength with size parameter equal to 0). All variants (assignment Unassigned). All ANSI strings (empty string assignment). Pay attention to the last point (s): this is the most common source of memory leaks when working with simple objects in KOL projects.

 

 

If you inherit your object type directly from the TObj type, then there is no special need to call the inherited method in your implementation of the Init method (this method does nothing in the TObj object itself).

 

And even if there is a constructing function, it is desirable to transfer that part of the object initialization that does not depend on parameters into the Init method. And remember that when working with simple objects, the word override in your definition of the Init method should not be used: instead, you should use the word virtual again (see example on the right).

 

 

If you inherit your object type directly from the TObj type, then there is no special need to call the inherited method in your implementation of the Init method (this method does nothing in the TObj object itself).

 

And even if there is a constructing function, it is desirable to transfer that part of the object initialization that does not depend on parameters into the Init method. And remember that when working with simple objects, the word override in your definition of the Init method should not be used: instead, you should use the word virtual again (see example on the right).


type

PmyType = ^ TmyType;

TmyType = object (Tobj)

Protected

MyStrProp: string;

MyStrList: PStrList;

...

procedure Init; virtual;

destructor Destroy; virtual;

...

 

// implementation:

procedure TmyType.Init;

begin

// inherited; - not needed

MyStrProp: = 'OK';

MyStrList: = NewStrList;

end;

Likewise, for the Destroy destructor: write virtual instead of override. But it is necessary to call inherited, and usually before exiting the destructor, when all its actions to release unnecessary resources have already been completed. Sometimes some actions can be performed after calling the inherited destructor, but in no case should this be a call to the fields of a remote object. Immediately after returning from inherited, the object no longer exists in memory, and an attempt to access them can lead to fatal consequences for the program.

destructor TmyType.Destroy;

begin

MyStrProp: = '';

MyStrList.Free;

inherited; // needednecessarily

end;

 

KOL / MCK User Guide - Created by Carl Peeraer - Diamant Soft, based on the work of Vladimir Kladov - Artwerp.be

  

Keyboard Navigation

F7 for caret browsing
Hold ALT and press letter

This Info: ALT+q
Nav Header: ALT+n
Page Header: ALT+h
Topic Header: ALT+t
Topic Body: ALT+b
Exit Menu/Up: ESC