lucamar is right.
Here's a little "topo", concerning memory management. There are few golden rules to which, we must adhere, if we want to manage memory well:
- the place where memory has been allocated (
or
oMyObject.create(TheOwnerIfAllowed)
), is the place where this memory must be released (
dispose(pMyRecord); ptr:= nil;
, or
, or
oMyObject.Free; oMyObject:= nil
).
==> This means that the allocations in the heap that are generally made at the beginning of a procedure, must be made in the opposite order of the allocations, at the end of
the same procedure: the code can be refactored by calling subroutines, but always in order to respect this golden rule!
- if sub-components are created by encapsulation in a proprietary component, what is created in the proprietary component's constructor must be destroyed in the opposite direction of their construction, in the proprietary component's destructor.
Taking into account what I just said, your images are contained in your dialog box: so, if you create them in your formCreate event, you must destroy them in the formDestroy event.
By sticking to these simple rules, and assigning nil to pointers whose memory has been released (
use FreeAndNil wherever you can; otherwise use dispose or Free and then, think to assign just behind the pointer with nil!), this allows you to destroy testing with
if Assigned(oMyObject) then FreeAndNil(oMyObject);
Then, to go further in the understanding of Free Pascal, there are two important notions whose documentation must be read:
- the owner (which is either the first AOwner parameter passed to a constructor), or a TForm or Tframe on which a control is placed,
by drop from the pallet. The owner has the responsibility to destroy everything he owns: it avoids calls to FreeAndNil. That said, if you are a little paranoid, the rules explained above should be able to continue making "safe" paranoid calls to FreeAnNil in the places I've indicated (which are bijective in places of their explicit creation).
- the parent: the parent of a visual control is simply the visual component on which your visual component is placed on. A control (ie a visual component) can therefore jump visually from one control to another, if you change programatically its parent property (for example, it can jump from a container like TPanel towards another like TGroupBox). That's all: it has nothing to do with memory management.
I'm going to say it again: you really have to do everything, but really do everything - otherwise, it will come back to you "in your teeth" sooner or later - to set your pointers with nil after having misallocated the memory on which they pointed, because internally, their Free and Destroy methods also use a test similar like: if (pMyRecord <> nil) then "release"
If the pointer still has an address in the heap but its content has been released (but it's not constant: it depends on what runs in addition with Laz. on your PC, the memory previously allocated can be partially reset with other things), then its destruction will result in a "memory access violation" at 99% .

==>
by not assigning with nil your "unallocated" pointers, you will go straight towards fuck*** dangling pointers problems, with "memory access violation".(one last thing: there is also the management of
interface memory, which is a completely different world. I say that, in case you are asked to use them to create \ use a COM server, or to do behavioral polymorphism's logic, instead of inheritance polymorphism's logic, and if you are prevented from using
Helper for TMyClass that allow you to stay in inheritance polymophism's logic).