BorlandTalk.com

Neal O'Connell · Guest

I've read that setting an interface variable to nil will destroy the
referenced object. I'm trying to do this, but having odd behavior.

I've learned that the following code does not work for this:

var
Interface1: TInterface1;
begin
Interface1 := CoInterface1.Create;
Interface1.Proc1;
Interface1 := nil;

// Application.ProcessMessages;

Interface1 := CoInterface1.Create;
Interface1.Proc1;
Interface1 := nil;
end;

If I leave the Application.ProcessMessages commented out, I've learned
that the TInterface1 object is not actually destroyed. Uncomment that
line and the object does get destroyed.

A few questions:

1 - is there a better way to force a referenced interface object to
destroy itself?
2 - if not, is it just a fluke that Application.ProcessMessages works
for me? Can I expect this workaround to work all the time on all
computers when I release my application into the wild?

Some details about why I need this to work. I'm working with a pair of
third party COM objects (each is a separate DLL) that both access the
same external data file. From what I can tell, they each seem to load
the contents of the file at creation. At one point I need to change the
contents of the data file through one object and then read them up
through the other.

My problem is that even though I set the 'read' interface variable to
nil after every use, it doesn't appear to get destroyed and the second
call to CoCreate just accesses the initial object (reference counting
it). So the 'read' object still has an old copy of the data file.

On a whim I tossed in an Application.ProcessMessages after setting the
variable to nil to see if that would help and it seemed. But I'm
uncertain if that's a full fix for my problem or just a sloppy hack.

Additional - it doesn't matter if the 'read' object is created twice in
a single procedure or if it is created once in a procedure and that
procedure is called twice. Both give the same bad results.

A third question:

3 - Is it possible that this is more of an issue with unloading the DLL?
If so, how do I wait until the DLL is unloaded?

I'm using D7 Pro Build 7.1 on winXP sp1.

Thanks,
Neal

Neal O'Connell · Guest

Anyone have any suggestions for a different newsgroup to post this question?

Thanks,
Neal

Tyro Abecedarian · Guest

"Neal O'Connell" wrote...

[portions elided]