Modifier valeur TStringList [Résolu]

Sat83 172 Messages postés mardi 11 novembre 2003Date d'inscription 13 octobre 2008 Dernière intervention - 29 mars 2007 à 17:24 - Dernière réponse : cs_mounjetado 69 Messages postés lundi 13 mars 2006Date d'inscription 4 août 2008 Dernière intervention
- 26 sept. 2007 à 16:05
Bonjour!

Je voudrais modifié une valeur dans une TStringList.

J'ai donc créer la méthode:

var myList : TstringList;
[...]

procedure TMyObjet.changeValue(const index:word; const str : String);
begin
  if (index<=myList.Count)) then begin
    myList.Delete(index);
    myList.Insert(index,str);
  end;
end;

A prioris ça semble marché correctement (j'ajoute aussi que la TStringList n'est pas triée), mais je souhaiterais savoir si il y a une autre solution, ou si celle-çi vous semble correcte...

Merci de votre avis..
Afficher la suite 

8 réponses

Répondre au sujet
Loulibier 323 Messages postés jeudi 6 juin 2002Date d'inscription 24 septembre 2008 Dernière intervention - 29 mars 2007 à 17:54
+3
Utile
Bonjour Sat83,

voici une autre solution qui semble être plus simple :

procedure TMyObjet.changeValue(const index:word; const str : String);
begin
  if (index < myList
.Count) then 
    myList[index] := str;

end;

Cette méthode t'évite de supprimer ton enregistrement et d'en rajouter un nouveau.

Bonne Prog,  Olivier
PS : Lorsqu'une réponse vous convient, n'oubliez pas de la valider.
Cette réponse vous a-t-elle aidé ?  
Commenter la réponse de Loulibier
WhiteHippo 1270 Messages postés samedi 14 août 2004Date d'inscription 5 avril 2012 Dernière intervention - 29 mars 2007 à 18:53
+3
Utile
Bonsoir
Juste histoire d'être puriste  et surtout de mettre mon grain de sel , une vérification de l'existence de MyList ainsi qu'un index du type Integer serait plus adéquate. De plus, il n'est pas nécessaire de vérifier l'index, cela est fait dans la classe de base. Un bloc try..except suffit à intercepter l'éventuelle erreur.

procedure TMyObjet.changeValue(const index:Integer; const str : String);
begin
 
if ( myList<>NIL ) then
  try

    myList[index] := str;
  except
    // traitement ici en cas d'erreur
    // exemple :
    On E:Exception do
      ShowMessage( E.Message ) ;
  end ;
end;

Cordialement.



<hr />
"L'imagination est plus importante que le savoir." Albert Einstein
Cette réponse vous a-t-elle aidé ?  
Commenter la réponse de WhiteHippo
f0xi 4304 Messages postés samedi 16 octobre 2004Date d'inscription 9 mars 2018 Dernière intervention - 30 mars 2007 à 07:46
0
Utile
tout simplement :

procedure TMyObjet.changeValue(const index : integer; const str : String);
begin
  MyList[index] := str
end;

ou

procedure TMyObjet.changeValue(const index : integer; const str : String);
begin
  if MyList[index] <> str then
    MyList[index] := str
end;

ou

procedure TMyObjet.changeValue(const index : integer; const str : String);
begin

  if index < MyList.Count then
  { if (index < MyList.Count) or (MyList.Count = 0) then }

     MyList[index] := str

  else

     MyList.Add(Str);
end;

ensuite l'objet MyList doit appartenir a l'objet MyObject ... un objet ne doit en aucun cas (du moins la plupart du temps et dans les cas generaux) faire appel a un objet externe si ce dernier n'est pas utilisé ailleur.

TMyObjet = class({ancetre})
private
  fMyList : TStrings;
  fOnChange : TNotifyEvent;
  procedure SetMyList(val : TStrings);
protected
  procedure Change; virtual;
public
  constructor Create; {override;}
  destructor Destroy; {override;}
  property fMyList : TStrings read fMyList write SetMyList;
  property OnChange :  TnotifyEvent read fOnChange write fOnChange;
end;

constructor TMyObject.Create;
begin
  inherited Create;
  fMyList := TStringList.Create;
end;

destructor TMyObject.Destroy;
begin
  fMyList.Free;
  inherited Destroy;
end;

procedure TMyObject.Change;
begin
  if Assigned(fOnChange) then
     fOnChange(Self);
end;

procedure TMyObject.SetMyList(val : TStrings);
begin
  fMyList.Assign(val);
  Change;
end;

aussi, c'est une erreur de mettre des parentheses dans un if quand il n'y a qu'une seule condition :

correct :

if truc <= machin then
if truc in machin then
if truc then
if not truc then
if not (truc in machin) then
if not (truc = machin) then
if (X mod 2) = 0 then
if not ((X mod 2) = 0) thenif (truc <machin) or (truc> machin) then
if (truc = machin) and (machin <> bidule) then
if CheckBox1.Checked and CheckBox2.Checked and CheckBox3.Checked then

incorrect :

if (truc <= machin) then
if (truc in machin) then
if (not truc) then
if ((truc = machin) and (machin <> bidule)) then

because Delphi is not C++

et il en vas de meme pour while ou repeat ...

<hr size="2" width="100%" />Croc (click me)
Commenter la réponse de f0xi
WhiteHippo 1270 Messages postés samedi 14 août 2004Date d'inscription 5 avril 2012 Dernière intervention - 30 mars 2007 à 09:16
0
Utile
Hello foxi,

"aussi, c'est une erreur de mettre des parentheses dans un if quand il n'y a qu'une seule condition" [...] "because Delphi is not C++"???

Je vois pas en quoi c'est une erreur et surtout en quoi sa se rapproche du C++ ?

 Tout d'abord, le compilateur l'accepte de par sa grammaire formelle :

InstructionIf -> IF Expression THEN Instruction [ELSE Instruction]
Expression -> ExpressionSimple [OpRel ExpressionSimple]...
ExpressionSimple -> ['+' | '-'] Terme [OpAdd Terme]...
Terme -> Facteur [OpMul Facteur]...
Facteur -> Désignateur ['(' ListeExpr ')']
       -> [mailto:'@' '@'] Désignateur
       -> Nombre
       -> Chaîne
       -> NIL
       -> '(' Expression ')'
       -> NOT Facteur
       -> ConstructeurEnsemble
       -> IdentType '(' Expression ')'

Ensuite, d'un point de vue logique si l'on met des parenthèses avec des conditions multiples, il est normal d'en mettre également dans une condition simple.

En résumé :
  Ce n'est pas une erreur !

P.S. Pour le repeat et le while, c'est idem.

Cordialement.
<hr />"L'imagination est plus importante que le savoir." Albert Einstein
Commenter la réponse de WhiteHippo
florenth 1105 Messages postés dimanche 1 août 2004Date d'inscription 17 août 2008 Dernière intervention - 30 mars 2007 à 15:53
0
Utile
Ce n'est pas une erreur, c'est juste inutile.

Tout comme écrire :
var
Bool: Boolean;
begin
if (Bool = True) then
begin
DoSomething();
end;
end;

car :
- "if Bool True"> "if Bool".
- Pas besoin de parenthèses autour.
- begin..end inutile si une seule ligne.
- parenthèses à la procédure inutiles si pas de paramètres.

En gros, en allégé, ça donne ça:
var
Bool: Boolean;
begin
if Bool then
DoSomething;
end;

C'est quand même plus clair qu'avant.
Et encore, j'ai pas fait le coup de l'indentation foireuse où on saute 2 lignes entre le then et le begin ...

Ce ne sont que des détails, mais je pense que bien coder, c'est surtout et avant tout bien écrire.
Un code fonctionnel ne suffit pas: il faut qu'il soit maintenable.
Donc il fait qu'il soit lisible.
Donc il faut que le gars qui code écrive bien.
Donc il faut un minimum de respect quand aux nomenclatures.

Voila.
Commenter la réponse de florenth
WhiteHippo 1270 Messages postés samedi 14 août 2004Date d'inscription 5 avril 2012 Dernière intervention - 30 mars 2007 à 16:32
0
Utile
"Un code fonctionnel ne suffit pas: il faut qu'il soit maintenable."


Entièrement d'accord , cependant lequel de ces deux codes :

// Code 1
var
  Bool : Boolean ;
begin
  if Bool then
    DoSomething ;
end;
 
// Code 2
var
  Bool : Boolean ;
begin
  if ( Bool ) then
  begin
    DoSomething ;
  end ;
end ;

est le plus facile à maintenir si tu as :
  - une condition à ajouter à ton if : Exemple ( a and (b+c))
  - plusieurs actions à effectuer dans ton if : Exemple, DoSomething1 et DoSomething2  

Sans hésitation, c'est le code 2.
"- "if Bool True"> "if Bool".
- Pas besoin de parenthèses autour.
- begin..end inutile si une seule ligne.
- parenthèses à la procédure inutiles si pas de paramètres."
Dans tous ces cas, c'est avoir une vision à court terme que de ne pas mettre des parenthèses et/ou des begin..end, et donc c'est de ne pas envisager d'éventuelles futures modifications.

"Donc il fait qu'il soit lisible."
Les parenthèses, les begin..end ne gènent en rien la lisibilité, bien au contraire.

"Donc il faut un minimum de respect quand aux nomenclatures."
Je suppose que c'est aux normes que tu faisais allusions.

Cordialement.
<hr />"L'imagination est plus importante que le savoir." Albert Einstein
Commenter la réponse de WhiteHippo
florenth 1105 Messages postés dimanche 1 août 2004Date d'inscription 17 août 2008 Dernière intervention - 30 mars 2007 à 16:51
0
Utile
On ne doit pas avoir la même version du mot "lisible" (le code 2 est bien trop lourd à mon goût, pour le peu qu'il fait ...) mais bon, chacun fait comme il le sent après tout...

Pour "norme" vs. "nomenclature" tu a tout à fait raison. Remarque, ça me permet de dire qu'utiliser une nomenclature stricte pour les noms de variables, etc améliore grandement la lisibilité.
Commenter la réponse de florenth
cs_mounjetado 69 Messages postés lundi 13 mars 2006Date d'inscription 4 août 2008 Dernière intervention - 26 sept. 2007 à 16:05
0
Utile
pour ma part, je pense que vous vous prenez la tête sur des histoires de sémiologie, pourdéfendre vos points de vue respectifs (ce que je comprends tout à fait) mais...
en définitive, ça dépend du degré de complexité du code à produire, non?
enfin, je peux me tromper et je ne veux pas donner des leçons à des personnes certainement beaucoup plus efficaces que moi en matière de programmation...
sur ce, je retourne dans les entrailles de mon système... si on me demande, dites que nous ne m'avez pas vu, ok? lol
mes salutations admiratives à vous tous!

<hr />si Delphi m'était conté...
Commenter la réponse de cs_mounjetado

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.