Comment libérer / finaliser correctement une DLL ActiveX dans Delphi?

Question

Nous utilisons ici une classe appelée ODNCServer - à l'initialisation, un objet TAutoObjectFactory est créé:

initialization
  pAutoObjectFactory := TAutoObjectFactory.Create(ComServer, TODNCServer, Class_ODNCServer, ciSingleInstance, tmApartment);

Maintenant, FastMM se plaint d'une fuite de mémoire car cet objet n'est libéré nulle part. Si j'ajoute une déclaration de finalisation comme celle-ci

finalization
  if assigned(pAutoObjectFactory) then
    TAutoObjectFactory(pAutoObjectFactory).Free;

l'objet est alors libéré, mais après , la boîte de dialogue FastMM relative à la fuite de mémoire apparaît. En fait, le système d'exploitation semble décharger la DLL, pas le programme. Les instances de ODNCServer sont créées comme suit

fODNCServer := TODNCServer.Create(nil);
//register into ROT
OleCheck(
 RegisterActiveObject(
   fODNCServer.DefaultInterface,            // instance
   CLASS_ODNCServer,    // class ID
   ACTIVEOBJECT_STRONG,       //strong registration flag
   fODNCServerGlobalHandle //registration handle result
 ));

et libéré comme ceci:

if ((assigned(fODNCServer)) and (fODNCServerGlobalHandle <> -1)) then
begin
  Reserved := nil;
  OleCheck(RevokeActiveObject(fODNCServerGlobalHandle,Reserved));
  fDTRODNCServerGlobalHandle := -1;
end;
FreeAndNil(fODNCServer);

Alors, est-ce que quelqu'un sait ce que je dois changer pour me débarrasser de cette fuite de mémoire? En passant, j’ai aussi essayé d’utiliser le RegisterExpectedMemoryLeaks de FastMM pour enregistrer et ignorer la fuite, mais cela ne semble pas fonctionner. De plus, même si ce ne serait qu'une solution de contournement, j'aimerais savoir la bonne façon de procéder.

Answer 1

Ne vous inquiétez pas pour ça. Ce n'est pas une " fuite " au sens strict. Oui, vous créez un objet qui n'est jamais gratuit, mais le mot clé est "an". Singulier.

Votre application / DLL ne "va pas fuir". la mémoire dans le sens où elle créera de nombreuses instances de ces objets, augmentera continuellement son utilisation en mémoire. De plus, la mémoire utilisée par cet objet fabrique unique (et d’autres objets similaires) sera nettoyée à la fin du processus.

Si vous montriez le code que vous utilisez pour appeler RegisterExpectedMemoryLeak () , il serait peut-être possible de déterminer pourquoi il ne fonctionne pas dans votre cas spécifique.