I am using Assigned to check for the existence of a component.

After issuing a ComponentName.Free though the component no longer exists Assigned returns True.

-----------------------------------------------------
if Assigned(frm) then
 s := 'Assigned'
else
 s := 'Not Assigned';

frm := Tfrm.Create(nil);    // create form
frm.Free;    // free form

if Assigned(frm) then
 s := s + ' || Assigned'
else
 s := s + ' || Not Assigned';

ShowMessage(s);
---------------------------------------------------------

This returns 'Not Assigned || Assigned'. How can I get a 'Not Assigned' after freeing the component?

In this post I am seeing Tim stated that Free works as FreeAndNil.

However, this is a message from year 2013 and EWB1.

http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=2191

<<
Trinione wrote:

I am using Assigned to check for the existence of a component.
After issuing a ComponentName.Free though the component no longer exists Assigned returns True.

frm := Tfrm.Create(nil);    // create form
frm.Free;    // free form

>>


That would be correct - technically that just frees memory.

If you need to check for assign after freeing the object then you must assign nil value to it.

...
frm.Free;
frm := nil;


Raul

Ha ha ha ha ha ha ha... I am here laughing at myself! Free And NIL... Free and NIL!!!

Thanks Raul.

After getting an error and reading up on it, first dereference the object before deallocating the memory.

 frm := nil;
 frm.Free;

<< After getting an error and reading up on it, first dereference the object before deallocating the memory. >>

No, that is backwards.  Calling Free will make sure that all resources owned by the object are disposed of.  Setting the variable to nil will make sure that the garbage collector in the JS engine in the browser knows that the instances is no longer referenced, and the GC will reclaim the memory in the next cleanup cycle.  If you set the reference to nil and then call Free, you're just introducing a NULL exception bug in your application that may or may not appear at runtime, depending upon when the GC gets around to cleaning up the reference.

EWB 1.x had a "magic" compiler FreeAndNil() type of operation, but I got rid of it in EWB 2.x because it didn't work well in certain constructs like when used with a "with" block.  So, in EWB 2.x, you explicitly need to do both:

MyInstance.Free;
MyInstance:=nil;

Tim Young
Elevate Software
www.elevatesoft.com

That should be "instance is", not "instances is".

Tim Young
Elevate Software
www.elevatesoft.com

<< MyInstance.Free;
MyInstance:=nil; >>

When I do it this way I get an instant error every time.

I am calling it after an animation when I move the form off the screen. Putting nil first is the only way it works.

I got the approach from the description on this page:
http://www.delphibasics.co.uk/RTL.asp?Name=freeandnil
which states: It actually does this in reverse order - first dereferencing the object before deallocating the memory.

<< When I do it this way I get an instant error every time. >>

Then you've got a bug somewhere.

<< I am calling it after an animation when I move the form off the screen. Putting nil first is the only way it works. >>

Email me an example of what you're trying to do and I'll respond here with the resolution.

<< I got the approach from the description on this page:
http://www.delphibasics.co.uk/RTL.asp?Name=freeandnil
which states: It actually does this in reverse order - first dereferencing the object before deallocating the memory. >>

Yes, but it *saves* a reference to the instance in a local variable before setting the original reference to nil, and then frees *the local variable*.  The logic there is that you don't want the *original* variable still pointing to memory that has been freed because there was an exception during one of the Destroy calls inside of the class hierarchy.

You can't do the exact same thing as FreeAndNil with EWB because it doesn't support variable parameters.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> EWB 1.x had a "magic" compiler FreeAndNil() type of operation, but I
> got rid of it in EWB 2.x because it didn't work well in certain
> constructs like when used with a "with" block.

Sounds like you fixed that one the wrong way around. Removing "with"
would have been better.  8-)

--

Matthew Jones