....Oui. J'ai un souci avec une de mes applications dans ce contexte.
J'ose pas imaginer si...

Bon.

C'est pas handicapant. Mais l'application génère une GPF lorsqu'on la
ferme.

Un truc pour réussir à la faire planter à chaque fois, c'est d'ouvrir
une fenêtre avec une DBLookupComboBox. Mais parfois ça plante dans
d'autres contextes... Sinon, la plupart du temps ça se fermer sans souci.

Ca n'a lieu qu'avec Windows 98.

Z'avez déjà rencontré ça ?...

Ma prochaine étape pour résoudre ce détail, ça sera d'installer Delphi
sur ma VM W98... mais réinstaller une nouvelle fois, encore, tous les
composants, ça commence à me casser les pieds... (une fois sur Vistax64,
une fois sur W2K3x64, une fois sur XPx64... en moins d'un mois... oui,
ce n'est que 3 fois, c'est pas grand chose... mais à chaque fois qu'il
me propose d'activer le logiciel auprès de Borland, ça me file des
boutons, je me dis que ça va me le refuser, que je vais me retrouver
dans la mouise... soupirs...)

BigGrizzly a écrit :
> ...Oui. J'ai un souci avec une de mes applications dans ce contexte.
> J'ose pas imaginer si...


Si tu as 10.000€ sous la main là, veux bien passer une journée sur ton problème....

Gratos, deux pistes :
1 -
J'ai eu autrefois ce pb avec un autre composant( je ne rappelle plus
lequel).
Voici ce que j'avais trouvé en suivant pas à pas le code
du composant :
une fonction API windows dans system.pas n'était plus dans le kernel32
mais dans une autre dll (shell32.dll ou quelque chose comme ça). Elle était
appelée
lors de la destruction de l'objet.
Un test de version de windows avec un chargement dynamique de l'adresse
de la fonction dans la bonne dll, et tout était rentré dans l'ordre.
C'est une piste qui vaut ce qu'elle vaut.
Elle m'avait coûté quelques nuits blanches.
Très mauvais souvenir que je ne te souhaite pas vivre ...
Je dispose encore d'un Win 98 avec D6 pour éventuelle compil si ça passe et
si ça te dis.

2 -
Libération a tort par delphi à la fermeture de la forme du composant déjà
libéré
à la mimine (à force de vouloir éviter les fuites de mémoire et faire très
propre, voila ce qui arrive !).
Je ne sais pas si le composant est créé dynamiquement ou pas,
mais ce point peut mériter que l'on s'y intéresse. Surtout s'il y a création
dans une boucle
ou dans une fonction récursive.
Pour ma part, j'avais simplement supprimé un FreeAndNil(...) et tout était
rentré dans l'ordre

Voila voila voila ...

--
Phil



"FOST©" <exe@dll.com> a écrit dans le message de news:
fmlbme$irj$2@sd-6498.dedibox.fr...
> BigGrizzly a écrit :
>> ...Oui. J'ai un souci avec une de mes applications dans ce contexte.
>> J'ose pas imaginer si...
>
>
> Si tu as 10.000€ sous la main là, veux bien passer une journée sur ton
> problème....

sheep a écrit :
> Gratos, deux pistes :
> 1 -
> J'ai eu autrefois ce pb avec un autre composant( je ne rappelle plus
> lequel).
> Voici ce que j'avais trouvé en suivant pas à pas le code
> du composant :
> une fonction API windows dans system.pas n'était plus dans le kernel32
> mais dans une autre dll (shell32.dll ou quelque chose comme ça). Elle était
> appelée
> lors de la destruction de l'objet.
> Un test de version de windows avec un chargement dynamique de l'adresse
> de la fonction dans la bonne dll, et tout était rentré dans l'ordre.
> C'est une piste qui vaut ce qu'elle vaut.
> Elle m'avait coûté quelques nuits blanches.
> Très mauvais souvenir que je ne te souhaite pas vivre ...
> Je dispose encore d'un Win 98 avec D6 pour éventuelle compil si ça passe et
> si ça te dis.
>
> 2 -
> Libération a tort par delphi à la fermeture de la forme du composant déjà
> libéré
> à la mimine (à force de vouloir éviter les fuites de mémoire et faire très
> propre, voila ce qui arrive !).
> Je ne sais pas si le composant est créé dynamiquement ou pas,
> mais ce point peut mériter que l'on s'y intéresse. Surtout s'il y a création
> dans une boucle
> ou dans une fonction récursive.
> Pour ma part, j'avais simplement supprimé un FreeAndNil(...) et tout était
> rentré dans l'ordre
>
> Voila voila voila ...
>


Merci pour tes suggestions. J'imagine que je vais tomber sur un truc de
ce genre... mais il faut que j'installe D7+tous les composants sur la
machine virtuelle W98 pour tester cela... :-) Zut.

> Gratos, deux pistes :
> 1 -
> J'ai eu autrefois ce pb avec un autre composant( je ne rappelle plus lequel).
> Voici ce que j'avais trouvé en suivant pas à pas le code
> du composant :
> une fonction API windows dans system.pas n'était plus dans le kernel32
> mais dans une autre dll (shell32.dll ou quelque chose comme ça). Elle était
> appelée
> lors de la destruction de l'objet.
> Un test de version de windows avec un chargement dynamique de l'adresse
> de la fonction dans la bonne dll, et tout était rentré dans l'ordre.
> C'est une piste qui vaut ce qu'elle vaut.
> Elle m'avait coûté quelques nuits blanches.
> Très mauvais souvenir que je ne te souhaite pas vivre ...
> Je dispose encore d'un Win 98 avec D6 pour éventuelle compil si ça passe et
> si ça te dis.
>
> 2 -
> Libération a tort par delphi à la fermeture de la forme du composant déjà
> libéré
> à la mimine (à force de vouloir éviter les fuites de mémoire et faire très
> propre, voila ce qui arrive !).
> Je ne sais pas si le composant est créé dynamiquement ou pas,
> mais ce point peut mériter que l'on s'y intéresse. Surtout s'il y a création
> dans une boucle
> ou dans une fonction récursive.
> Pour ma part, j'avais simplement supprimé un FreeAndNil(...) et tout était
> rentré dans l'ordre
>
Il me semble avoir déjà rencontré le problème n° 2

--

Dominique

> Merci pour tes suggestions. J'imagine que je vais tomber sur un truc de ce
> genre... mais il faut que j'installe D7+tous les composants sur la machine
> virtuelle W98 pour tester cela... :-) Zut.

Je fais souvent ça !
mais au lieu de me gonfler avec les compos, je les installe tous dans le
même répertoire (exemple Delphi7\imports) après, je n'ai plus qu'a
installer une version vierge de Delphi sur une machine virtuelle et recopier
ce répertoire avec la clé 'Borland' dans la base de registre.
Ca prend 3 minutes et ca fonctionne nickel.

Addendum :
Dans le destructeur de la classe, un inherited (destroy, évidemment)
placé AVANT la destruction de certains objets de la classe !

--
Phil


"TedIF" <TedIf@TedIF.fr> a écrit dans le message de news:
mn.8be67d81958acba2.65892@TedIF.fr...
>> Gratos, deux pistes :
>> 1 -
>> J'ai eu autrefois ce pb avec un autre composant( je ne rappelle plus
>> lequel).
>> Voici ce que j'avais trouvé en suivant pas à pas le code
>> du composant :
>> une fonction API windows dans system.pas n'était plus dans le kernel32
>> mais dans une autre dll (shell32.dll ou quelque chose comme ça). Elle
>> était appelée
>> lors de la destruction de l'objet.
>> Un test de version de windows avec un chargement dynamique de l'adresse
>> de la fonction dans la bonne dll, et tout était rentré dans l'ordre.
>> C'est une piste qui vaut ce qu'elle vaut.
>> Elle m'avait coûté quelques nuits blanches.
>> Très mauvais souvenir que je ne te souhaite pas vivre ...
>> Je dispose encore d'un Win 98 avec D6 pour éventuelle compil si ça passe
>> et si ça te dis.
>>
>> 2 -
>> Libération a tort par delphi à la fermeture de la forme du composant déjà
>> libéré
>> à la mimine (à force de vouloir éviter les fuites de mémoire et faire
>> très propre, voila ce qui arrive !).
>> Je ne sais pas si le composant est créé dynamiquement ou pas,
>> mais ce point peut mériter que l'on s'y intéresse. Surtout s'il y a
>> création dans une boucle
>> ou dans une fonction récursive.
>> Pour ma part, j'avais simplement supprimé un FreeAndNil(...) et tout
>> était rentré dans l'ordre
>>
> Il me semble avoir déjà rencontré le problème n° 2
>
> --
>
> Dominique
>
>