Discussion :

[Kephuro]

Bonsoir

Quand je développe je me retrouve souvent devant ce cas de figure, et j'aurais aimé connaitre votre façon d'y faire face.

Prenons un projet au hasard : Un programme qui permet de créer objet de type TUtilisateur pour en faire je ne sais quoi (l'ajouter dans une BDD tiens, ça lui apprendra). Cet utilisateur possède une collection de Bidules.

Donc voici notre utilisateur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
TUtilisateur=class
  private
    FAge: integer;
    FMesBidules: TList;
    FNom: string;
    procedure SetAge(const Value: integer);
    procedure SetMesBidules(const Value: TList);
    procedure SetNom(const Value: string);
 
  public
    constructor create;
    destructor destroy();override;
    property Nom:string read FNom write SetNom;
    property Age:integer read FAge write SetAge;
    property MesBidules:TList read FMesBidules write SetMesBidules;
  end;

Notre projet contient :

• Une form principale
• Une unité qui contient nos classes
• Une form modale qui permet d'ajouter un bidule à l'utilisateur

Ma question porte en réalité sur l'ajout d'un bidule. Bidule étant un objet de type TBidule (peu importe ce qu'il contient). Perso j'ai l'habitude que l'aboutissement de ma modale soit la création d'un objet bidule.
Cet objet étant ensuite ajouté à la liste des Bidules de l'utilisateur.

Ce qui m'embête, c'est qu'à ma connaissance une form ne peut pas renvoyer d'objet (au mieux elle renvoie un entier avec ModalResult).

Du coup ma solution crado consiste à créer une property de type TUtilisateur dans ma form modale.
Et lorsque ma form principale a besoin d'ajouter un Bidule, je fais quelque chose genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure TFormPrincipale.AjouterUtilisateur;
//Construction d'un objet de type TUtilisateur, on passe sur les détails de la création
//Maintenant on a besoin d'ajouter un bidule :
  frmAjoutBidule.UtilisateurCourant:=NouvelUtilisateur;
  if frmAjoutBidule.showmodal<>mr_Cancel then
  begin
    ShowMessage('Glop !');
    //Le Bidule a été ajouté
  end
  else
  begin
    ShowMessage('Pas glop !');
    //Le Bidule n'a pas été ajouté
  end;

La modale s'ouvre donc, et là on a des EditBox pour remplir les caractéristiques de notre objet Bidule, par exemple.
Lorsqu'on clique sur le bouton de validation de la form on instancie un Objet bidule, puis on vérifie qu'on a pas rentré de bêtises dans les EditBox et finalement nous avons notre objet Bidule. On fait un

Code :

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

UtilisateurCourant.add(Bidule);

et en général j'ajoute quelque chose du style :

Code :

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

1
2
UtilisateurCourant:=nil;
ModalResult:=mr_ok;

et là ma form modale se ferme et j'ai bien ajouté un objet Bidule à l'utilisateur.

Je trouve ma méthode vraiment "sale" et assez peu pratique.

Reste la solution d'utiliser une variable globale mais là bonjour la propreté...

Comment gérez-vous ce genre de "problème" (qui semble plus être une question existencielle finalement) ?
Dois-je concevoir mes applications différemment ?

[Aka Guymelef]

Personnellement je ne trouves pas que c'est une solution "crade" au contraire, c'est beaucoup mieux qu'une variable globale justement. Il faut considérer que cette propriété que tu ajoutes à ta fiche modale est comme un paramètre en entrée que tu passerais à une fonction pour que cette fonction la manipule.

Néanmoins si tu souhaites vraiment essayer une autre piste voici ce que je te propose. Définir un évènement personnalisé dans lequel tu passerais (en plus du Sender) l'objet TBidule qui vient d'être inséré en BDD. Et donc après c'est à celui qui implémente cet évènement de la fiche modale de faire ce qu'il veut du TBidule inséré (au hasard l'ajouter à TUtilisateur ).

C'est une autre façon de voire les choses.

[Rayek]

Personnellement je ne trouves pas que c'est une solution "crade" au contraire, c'est beaucoup mieux qu'une variable globale justement.

Je n'ai jamais compris cette haine des variables globales qu'ont certain
Les variables globales c'est bien, mais il faut faire attention quand et comment on les utilise, faut arreter de les diaboliser comme çà ...

@Kephuro : Sinon, autre possibilité, tu te crées ton propre ShowModal.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
type ECANCELMODAL = class(Exception);
 
type MaForm = class(TForm)
  private
  public
    function ShowModalNew : TBidule;
end;
 
implementation
 
function MaForm.ShowModalNew : TBidule;
begin
  case self.ShowModal of
    mrOk: ;// traitement des infos de TBidule avec Result
    // on génère une exception dans le cas de l'annulation.
    mrCancel,mrAbort: raise ECANCELMODAL.create('Annulation');
    else begin
      raise; // dans le cas d'une autre erreur ou retour de ShowModal
    end;
  end;
end;
 
end.

[Aka Guymelef]

Je n'ai jamais compris cette haine des variables globales qu'ont certain
Les variables globales c'est bien, mais il faut faire attention quand et comment on les utilise, faut arreter de les diaboliser comme çà ...

Ha mais je n'ai jamais dis qu'il ne faut jamais les utiliser, je dis qu'il faut plutôt les utiliser à bon escient (d'ailleurs même il y a des moments où c'est obligatoire de passer par là comme pour une fabrique de classe par exemple).

Néanmoins ici passer par une variable globale pour représenter un "buffer" où l'on stocke temporairement un objet pour qu'il puisse être modifié par un autre je trouves que c'est une faute de goût certain voire une source de problème si jamais il devait y avoir des accès concurrent (Thread). Et utiliser un paramètre de cette manière a plutôt tendance (du moins pour moi) à rendre le code moins lisible...

[Kephuro]

Voui, dans certains cas j'imagine qu'on a pas trop le choix (lesquels d'ailleurs ?).
Mais ça peut aussi témoigner d'erreurs de conceptions ou tout simplement de flemmardise .

C'est p'têtre pour ça que ça a mauvaise réputation