Discussion :

[jnspunk]

Bonjour,

Après pas mal de recherche sur ce sujet, je ne trouve pas de situations similaires.

J'ai un objet TabBiens de type TTabBiens qui est une classe dérivé d'un TObjectList.
Cet objet contient donc une liste d'objets, de type TBien.

Le problème qui se présente survient des fois lorsque j'assigne un TBien dans mon TTabBiens.
On voit sur la capture d'écran ci-dessous le contenu de Bien avant l'exécution de instruction surligné qui plante.



Avez vous une idée? Étrange d'apparence non?
Merci par avance.

[tourlourou]

est-ce que la liste est propriétaire des objets (OwnsObjects) ?
si oui, ne tente-t-elle pas de détruire un objet déjà libéré pour le remplacer par le nouveau ?

[ShaiLeTroll]

Self c'est TTabBiens
Donc cela appelle le Setter de Items de la TObjectList ou celui que tu as redéfini !
J'espère que Modifier n'est pas le Setter du "TBien Items[]" ?
Coder en français, ouais, pourquoi pas, c'est bcp d'effort je trouve, si tu es seul sur ton projet ok, mais si ton projet doit être repris par un autre développeur, si il connait bien Delphi, il ne retrouvera pas les habituelles Add, Delete, IndexOf ... dommage !

j'aurais plutôt écrit inherited Items[Index] := Bien;Si Modifier est le Setter, dommage de ne pas utiliser les conventions de nommage Get\Set\Put

Au lieu des Exit, utilise des Exceptions, tu caches les erreurs c'est dommage !

Sinon, comme Toulourou, attention au piège, lors de la modification de Items[], le SetItem \ Put appele le Notify qui supprime l'ancien Objet (et éventuellement le libère) puis "ajoute" le nouvel élément

[jnspunk]

Merci ça marche!
Je ne m'étais pas posé la question si le TOBjectList libérait ses objets à l'assignation !

Sinon pour les observation :

Coder en français, ouais, pourquoi pas, c'est bcp d'effort je trouve, si tu es seul sur ton projet ok, mais si ton projet doit être repris par un autre développeur, si il connait bien Delphi, il ne retrouvera pas les habituelles Add, Delete, IndexOf ... dommage !

Intéressante remarque ! L'objectif était justement dans l’intérêt que mon projet soit repris par un autre développeur. Je voulais que le développeur qui utilise ma classe sache en regardant ses définitions qu'elle est la classe utilisé pour les élément de sa liste. J'aurais pu surcharger Add, Delete... c'est vrai! Seulement dans ma boite ils sont plus familiarisé avec récupère et ajoute... C'est comme ça, faut s'y faire hihi

Au lieu des Exit, utilise des Exceptions, tu caches les erreurs c'est dommage !

Je ne comprend pas trop, les Exit me servent à rendre le code propre en évitant les Begin End / indentations inutiles. Pour gérer les erreurs que j'ai envie de gérer j'utilise les exceptions.


Merci à vous !

[ShaiLeTroll]

Dans ce cas, faut en sorte que Modifier renvoie au moins un boolean pour indiquer qu'il a réellement modifier et pas juste ignorer la demande car Index Hors limite !
Personnellement, c'est le genre d'erreur que je ne cache pas car elle ne DOIT JAMAIS se produire sinon c'est qu'il y a une erreur dans le code d'appel qui peut être source de bug

Pense aux autres, un développeur va appeler "Modifier" et ne va pas comprendre que l'objet n'a pas été remplacé !
plus loin dans le code, ce développeur peut supposer que l'ancien objet a été libéré et pensera que le nouvel objet inséré le sera aussi à la libération de la liste, mais comme le remplacement n'a pas eu lieu, conséquence une fuite mémoire !
Va déboguer ça !

En plus lancer du Windev en plein milieu, encore une fois, une gestion d'erreur séparée pour que le développeur puisse corriger son code et si il le décide remonter l'erreur par AppelWD !

sinon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (not Assigned(Bien) or (not (Bien is TBien) then

cela s'écrit tout simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not (Bien is TBien) then

Opérateur is :

renvoie True si objet est une instance de la classe désignée par classe ou de l'un de ses descendants, et False sinon. Si objet a la valeur nil, le résultat est False.

Je ne comprend pas trop, les Exit me servent à rendre le code propre en évitant les Begin End / indentations inutiles.

Mon Boss ne t'aimerais pas !
Un point d'entrée et Un point de Sortie !

en plus le code est plus court, plus logique car l'on teste le cas où la situation est OK et non pas le not OK !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
begin
  if Bien is TBien then
  begin
    if (0 < Index) and (Index <= Count) then
     inherited Items[Index] := Bien;
  end
  else
    AppelWD(...);
end;

Ah un très long débat, personne n'est jamais d'accord ...

[jnspunk]

Tout d'abord Merci pour ces informations ! Ca me fait évoluer et ça n'a pas de prix

sinon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (not Assigned(Bien) or (not (Bien is TBien) then

cela s'écrit tout simplement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if not (Bien is TBien) then

A la base c'était

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

If (not Assigned(Bien))

le reste je venais de l'ajouter pour tester si ça bugait toujours, je comptais bien sur faire le ménage après. Je l'ai laissé comme indice au cas où ça pouvait aider à trouve une solution

Je ne comprend pas trop, les Exit me servent à rendre le code propre en évitant les Begin End / indentations inutiles.
Mon Boss ne t'aimerais pas !
Un point d'entrée et Un point de Sortie !

Je l'ai appris en lisant le SDK de Quake 3, je ne sais pas si c'est une bonne référence mais je trouvais ça très utiles pour traiter les conditions en début de fonctions tout en évitant les bloc d'indentation démesuré.

D'habitude j'utlise des valeurs de retour, mais dans le contexte le résultat de MODIFIER est optionnel, aussi étrange que cela puisse paraître

Pour Windev, il faut que je fasse avec et garder "la logique" du programme, il est entièrement interfacé avec. (à 500 000 mille lignes de code, on réinvente pas la roue !)

Ps : Je suis sur que ton Boss m'aimerais car je serais heureux d'apprendre ses méthodes !!

[jnspunk]

Ah un très long débat, personne n'est jamais d'accord ...

Oui

L'expérience m'a apprit que chaque chose est viable dans son contexte. Tout dépend des besoins, des avantages et des inconvénients.
Comme ces caractéristiques ne sont que purement subjective, elle ne peuvent être les même chez d'autres personnes / entreprise.
J’apprécie beaucoup voir les autres méthodes car dans d'autres contextes elles me seront sans doutes très utiles.