Hello,
 
Encore un petit soucis. Il semblerait que lorsque qu'un TTImer est detruit, l'event onTimer qui a pu etre empile dans les messgaes windows soit depile apres l'appel au Free du TTimer. Du coup, on se retrouve avec une exception avec un read adress a 0000000. QQun a deja eu des problemes avec les TTImer et la destruction de ces objects ?
 
Merci,

Bizarre  
Si c'était ça je m'attendrais justement à une adresse autre que 0000000, vu que 000000 indique un pointeur nil.
 
Tu peux toujours désactiver le Timer puis faire un Application.ProcessMessages juste avant sa destruction, pour être sûr qu'il n'y ait pas un appel en attente dans les messages.

Deja essaye mais c'est pareil

Le bug est peut-être ailleurs alors... Tu ne détruis pas par hasard un objet dans un de ses événements ? Il n'indique pas à quel endroit du code arrive cet accès mémoire interdit ?

Voila le code execute:
  if (FT3Timer <> nil) then
  begin
    FT3Timer.Enabled:=False;
    FT3Timer.OnTimer:=nil;
    Application.ProcessMessages;
    FT3Timer.Free;
    FT3Timer := nil;
  end;
 
C'est la dedand que j'ai une exception

et ce code il se trouve où ? pas dans le OnTimer quand même ?
(t'as une exception sur quelle ligne ?)

Rigole pas si vite, ce code est dans une fonction (ce sont les seules lignes) qui est appele ds le ontimer !!
Sinon, je ne sais pas a quelle ligne cela arrive et comme l'exception est super chaude a reproduire ...

Bah c'est normal que ça plante alors :
 
on est dans une fonction Z du TTimer
déclanchement du ontimer
appel de ta fonction
destruction du timer
fin de ta fonction
retour dans le code de la fonction Z du TTimer... boum : on arrive dans un truc qui a été liquidé entre temps
 
Les fois où ça ne plante pas c'est quand, par chance, la zone mémoire du TTimer et tout ce qui y est relié est restée intacte bien que l'objet ait été supprimé.

Mais bon, ds le cas d'aujourd'hui, il a ete appele de l'exterieur

D'où ? À quel moment c'est appelé ? Le timer a été construit comment ?

Bon, la ca devient un peu complique pour tout expliquer
Ce timer est associe a un objet propre a notre soft:Transaction. Lors de l'envoi de la transaction, on va creer ce timer en executant cette fonction:
 
procedure TswSecsTransaction.SetT3Timer(Time : Integer);
begin
  KillT3Timer;
  if Time>0 then
  begin
    FT3Timer:=TTimer.Create(nil);
    FT3Timer.Enabled:=False;
    FT3Timer.OnTimer:=self.T3TimerOnTimer;
    FT3Timer.Interval:=Time;
    FT3Timer.Enabled:=True;
  end;
end;
 
Ensuite, lorsqu'on recoit la reponse a notre transaction (donc avant ce timer de timeout), on detruit le timer avec le code :
 
procedure TswSecsTransaction.KillT3Timer;
begin
  if (FT3Timer <> nil) then
  begin
    FT3Timer.Enabled:=False;
    FT3Timer.OnTimer:=nil;
    Application.ProcessMessages;
    FT3Timer.Free;
    FT3Timer := nil;
  end;
end;
 
Voila

Bizarre que ça plante...

Oui, le seul truc qu'on voyait a la limite c'est entre le free et le nil, que l'objet puisse etre appele si l'event avait ete empile mais bon, dans le ontimer, il check bien le assigned et la on le passe a nil avant de detruire donc ca devrait etre ok ...

Assigned c'est juste un test si <> nil
Il n'y a aucun moyen de savoir si un objet a été détruit ou non, à moins de le mettre à nil après destruction (ou en le passant à FreeAndNil en remplacement du Free et de la mise à nil).
Vu le code posté je dirais que le problème vient d'ailleurs dans le code, mais pour trouver d'où c'est pas évident