Discussion :

[Andnotor]

Désolé de te dire que tu n'as vraiment rien compris

• ModalResult ne détruit pas la fiche. Ce n'est qu'un propriété de type entier qui une fois settée permet de sortir de la boucle de messages.
• Free est obligatoire (si pas de caFree) sous peine de Memory leaks.
• Le terme "the form automatically closes" ne signifie pas sa destruction. Les données sont donc toujours en mémoire et accessibles. Mais bon, puisque tu ne parles pas l'anglais...
• Le passage de pointeur en paramètre n'a strictement rien à voir avec la durée de vie d'une fiche.

Embarcadero devrait faire appel à des développeurs pros pour modifier l'exemple fourni ...

J’espère que tu ne te considères pas comme l'un d'eux

[Paul TOTH]

Disponible en ligne

Si la fiche B est toujours en mémoire, il est possible de l'interroger via ses propriétés et ses fonctions membres tout comme les fiches non modales de l'exemple précédent.

le cas "Mais comment faire si la fiche B est retirée de la mémoire une fois fermée ?" n'est pas standard, et le code donné en exemple peut quand à lui être à l'origine d'un bug si la fiche est effectivement détruite et que ColorForm n'est pas forcé à nil.

Code :

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

1
2
3
4
5
6
7
 
 procedure GetColor(PColor: Pointer);
 begin
   ColorForm := TColorForm.CreateWithColor(PColor, Self);
   ColorForm.ShowModal;
   ColorForm.Free;
 end;

c'est cet article que je trouve écrit avec les pieds avec en prime le transtypage d'un string en Pointer ! En plus l'usage du Close force un ModalResult à mrCancel alors qu'on choisi une couleur...un non sens.

une bien meilleur proposition aurait été une fonction de classe qui se charge de tout.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
TColorForm = class(TForm)
   ColorListBox:TListBox;
   SelectButton: TButton;
   CancelButton: TButton;
   procedure CancelButtonClick(Sender: TObject);
   procedure SelectButtonClick(Sender: TObject);
 public
   class function GetColor(var Value: string): Boolean;   
 end;

[Ph. B.]

Ph. B. et Andnotor vous n'avez pas lu l'aide... faites l'effort

Et vous, vous faites l'effort de comprendre l'aide ? Voir ci-après !

Si je ne vous avais pas donné le lien c'est parce que nous sommes dans un site d'entraide et il me semble plus constructif d'éveiller votre curiosité.

D'une part, je ne vous ai jamais attendu pour éveiller ma curiosité ! D'autre part, dans mes messages sur ce site même, quand je fais référence à une FAQ, une doc, je donne un lien, ce que vous ne faites pas !

Lire :
ms-help://embarcadero.rs_xe2/rad/Récupération_des_données_des_fiches_modales.html

Enfin, on y arrive !
Cette page et ce qui est dit montre que vous n'avez compris que très partiellement le sujet et rejoint ma 1° remarque que vous avez ignorée !
Je cite :

Le code que vous avez donné ne plantera pas, ni ne renverra de réponse erronée, à moins que vous ayez omis une hypothèse sur mafiche2...

Cette phrase est en parfait accord avec ce que dit la doc, je cite :

Si la fiche B est toujours en mémoire, il est possible de l'interroger via ses propriétés et ses fonctions membres tout comme les fiches non modales de l'exemple précédent. Mais comment faire si la fiche B est retirée de la mémoire une fois fermée ? Comme une fiche ne renvoie pas explicitement de valeur, il est nécessaire de préserver les informations importantes de la fiche avant de la détruire.

Tout dépend donc de comment est fermée la fiche mafiche2 ce que l'on ne sait pas...
Si la fiche est conservée en mémoire, ses propriétés sont toujours accessibles et utilisables !
Si la fiche est libérée en mémoire, ce n'est plus vrai !
Comme je dis depuis le début, tout dépend donc des conditions sur la fiche mafiche2 qui sont actuellement indéfinies !
Andnotor l'avait également dit :

Il y a une incompréhension au niveau du ShowModal, mais aussi au niveau de la destruction de la fiche et de la persistance des données.
Ce bout de code n'inclut pas de Free ce qui laisse supposer que FormClose contient Action := caFree et dans ce cas en effet, l'accès ultérieur au données sera problématique (Le retour de la fonction devrait cependant être correct et le test valide puisque passé sur la pile...)

[jovanovic.radoslav]

Pour info je n'ai jamais dit que la fiche était détruite.
D'après la documentation on ne doit pas récupérer les infos de la fiche2 après le showmodal.
Le lien donné dans mon précèdent message renvoie sur la manière de le faire.

Andnotor tu refuses de lire la documentation, c'est bien dommage....
Es-tu allé voir le code du ModalResult : c'est sûr que non
As-tu vérifié qu'il y a bien un Memory Leaks si on ne fait pas un free dans le cas qui nous occupe càd l'affichage d'une fenêtre par ShowModal : c'est sûr que non.
Moi c'est une question que je me suis souvent posé, mais je n'ai pas d'outils pour le vérifier.
Si tu disposes d'un tel outil trouve le temps de faire un essai, s'il te plaît.
Peut-être avec le ReportMemoryLeaksOnShutdown. Il serait intéressant de comparer les 2 resultats.
Avant d'emmètre des certitudes vérifie-les, l'informatique change tellement vite.


Je ne suis pas un pro, j'ai juste 25 ans d'expérience en programmation dont 15 en delphi... et j'en apprends tous les jours et je doute tous les jours de mon savoir.


Ph. B. il n'y a aucune hypothèse à faire sur la fiche2.

Paul TOTH je vois que tu as lu les recommandations. MERCI.


Pour ceux qui ont lu la recommandation Embarcadero, j'espère que vous avez trouvé bizarre que l'on nous explique comment faire une chose en apparence aussi simple (mon mauvais code donné en exemple).

REPONSE : enfin pour comprendre pourquoi on doit suivre les recommandations Embarcadero sur la façon de récupérer les données provenant d'une fenêtre affichée par ShowModal, sachez que suite à une erreur (?) de programmation chez Borland lors de l'écriture du code gérant le ModalResult d'une fenêtre affichée par Showmodal, le programmeur a fait appel à une fonction qui informe le système d'exploitation que la mémoire
allouée càd celle de mafiche2 est à la disposition du système d'exploitation.

CONSEQUENCES : le système d'exploitation peut écrire dans la zone mémoire que le programmeur (càd nous) n'a pas encore libérée (c'est pour cela que je me demande si le free est bien utile dans ce cas ?). Et donc toutes les données récupérées, après le Showmodal, peuvent être erronées.

[Andnotor]

ModalResult, Le voici !

Code :

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

property ModalResult: TModalResult read FModalResult write FModalResult;

Du code, je peux pas t'en montrer, y'en a pas

A quoi sert-il ?..

Code :

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

1
2
3
4
5
repeat
  Application.HandleMessage;
  if Application.Terminated then ModalResult := mrCancel else
    if ModalResult <> 0 then CloseModal;
until ModalResult <> 0;

...il permet de sortir de la boucle de messages.

As-tu vérifié qu'il y a bien un Memory Leaks si on ne fait pas un free dans le cas qui nous occupe càd l'affichage d'une fenêtre par ShowModal...

Mon Dieu ! J'ai oublié d'fermer l'gaz...

...c'est sûr que non

...mais une chose est sûr ; soit tu reviens nous voir avec des exemples concrets, soit tu cesses de troller ou je à vue...

EDIT:
Ahh, C'était toi le... "collègue"

[Paul TOTH]

Ahh, C'était toi le... "collègue"

mouarf !!! troller sur un forum je connaissais, mais troller ses collègues c'est original

et pour compléter ta réponse, le CloseModal qui ne libère la fiche QUE sur un caFree, comme attendu.

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
 
procedure TCustomForm.CloseModal;
var
  CloseAction: TCloseAction;
begin
  try
    CloseAction := caNone;
    if CloseQuery then // True par défaut
    begin
      CloseAction := caHide; // cache la fiche sans la détruire
      DoClose(CloseAction); // appel de OnClose qui "peut" changer CloseAction
    end;
    case CloseAction of
      caNone: ModalResult := 0; // ne ferme pas la fiche
      caFree: Release; // détruit la fiche si OnClose retourne caFree
    end;
  except
    ModalResult := 0;
    Application.HandleException(Self);
  end;
end;

[SergioMaster]

SergioMaster il est dommage que tu n'aies jamais pris le temps de lire la documentation papier fournie par Borland puisque tu as utilisé les versions de D3 à D7 et l'aide en ligne jusqu'à D2010...

c'est sur a t'en croire je suis (nous sommes) une bille (des billes) . Ce n'est pas ma curiosité qui est frappée mais mon orgueuil

Je ne suis pas un pro, j'ai juste 25 ans d'expérience en programmation dont 15 en delphi...

bof on doit aligner le même nombre (faudrait qu'un jour je relise mon CV le temps passe si vite) .Moi aussi j'en apprend tous les jours et je m'estime loin d'être un kador de l'informatique (pour preuve j'ai toujours du mal avec les pointeurs) j'utilise régulièrement l'aide (en ligne ou papier) contrairement a ce que tu oses insinuer.
Pour en revenir a la doc papier , je peux même indiquer chapitre 9 et page (6 ..13) ce qui revient de toute façon , a peu de chose près a l'aide en ligne , et à comparer cela n'a pas bouger depuis D7 (il va falloir que je dépoussière mes manuels d3).
Enfin j'utilise cette technique de récupération de données depuis des années (je l'ai déjà dit je pense) certains de ces programmes tournent toujours quotidiennement et ce depuis 14 ans . De ce fait je pense pouvoir affirmer que :
- Cette technique pour récupérer des données d'une fiche modale fermée mais non libérée est fiable et exempte de fuite mémoire (si un Free est associé a une création dynamique , si il n'y a pas de caFree dans le onclose de la fiche modale , bref dans une bonne 'programmation'.

Plutôt que de lancer une 'rumeur/débat' sur un exemple Borland plutôt mal ficelé (pourquoi faire simple quand on peut faire compliqué) propose nous plutôt un exemple FichePrincipale + FicheModale avec récupération d'information simple (genre un texte,un nombre,une date) qui selon ton expression :

toutes les données récupérées, après le Showmodal, peuvent être erronées.

Dans le cas où cela se révèlerai positif , je m'amenderai et réviserais mes productions Delphi

[Paul TOTH]

ouah ! ça pique les yeux !

[jovanovic.radoslav]

Andnotor
Je pocède aussi les fichiers sources de delphi, mais ce n'est pas forcément ce code qui a été compilé pour produire mon delphi.

Je constate seulement les faits : que les programmeurs ne connaissent pas ces recommandations des éditeurs Borland, CodeGear et aujourd'hui Emarcadero et les autres ne les suivent pas.

SergioMaster
Je n'ai jamais rien dit de tel. Moi, je me pose seulement la question pourquoi la présence de ces conseils pour quelque chose en apparence simple à faire ? Toi cela ne te préoccupe pas ?
Ce n'est pas parce que ta méthode n'a jamais posé de problème que c'est forcément la bonne méthode.
Moi j'en emploie une autre depuis autant d'années que toi et cela ne pose pas de problème, mais est-ce la bonne ?

Bien sûr que je vous ferai part de ma méthode, mais le bug est aléatoire si tu as bien lu la partie réponse de mon message précèdent.

Paul Toth
Il faut aller sur le lien 2 fois un jour pair et un jour impair ça pique les yeux encore plus...bon d'accord je n'ai pas fait dans la modestie comme la plupart.

Posez-vous la question si ces infos sont inutiles pourquoi les avoir écrits et les maintenir pendant 15 ans ?

Pour ceux qui ont lu les recommandations, avez-vous fait attention que le même code est aussi en C++ ?

Enfin si mon mauvais code, donné en exemple, fonctionne correctement pourquoi alors ce conseil de faire autrement.....?

L'exemple donné utilise Addr qui est aujourd'hui obsolète : GetColor(Addr(MainColor));

Si ces infos sont obsolètes il faudrait demander à Embrcedero de les supprimées...

Quel est votre avis ?

Remarque : il me semble et si je me trompe je vous présente mes excuses, car cela était bien involontaire de ma part, n'avoir ni manqué de respect, ni m'être moqué de qui que ce soit, ni mis en doute les compétences de chacun.
Nous sommes sur un forum d'entraide et de réflexion ou pas ?

[Paul TOTH]

tu as raison...on ne peut pas laisser faire ça

[jovanovic.radoslav]

Peux tu être plus clair s'il te plaît ?

l'aide dit....
Par conséquent, ShowModal ne renvoie rien avant la fermeture de la fiche. Lorsque la fiche se ferme, elle renvoie la valeur de la propriété ModalResult.

Le lien renvoi sur un exemple qui se base sur la valeur du showmodal donc du ModalResult or les conseils données ne l'utilisent pas puisque sa valeur peut être fausse... car le Modalresult appartient à la fiche qui est affichée par le showmodal ? et si on ne doit pas récupérer les valeurs après le showmodal....

[Andnotor]

l'aide dit....
Par conséquent, ShowModal ne renvoie rien avant la fermeture de la fiche. Lorsque la fiche se ferme, elle renvoie la valeur de la propriété ModalResult.

Ce qui veut simplement dire que la fonction est blocante

Ce qu'on aimerait surtout avoir est le lien sur une page officielle Embarcadero disant spécifiquement "Les propriétés d'une fiche peuvent être (sont) indéterminées au retour de ShowModal".

Le Result renvoyé par ShowModal ne peut pas être faux !
Même si on suivait ta logique (!), comme tout appel de fonction, on n'accède pas directement à ModalResult, mais à une copie dans un registre (ou sur la pile).

Un peu de lecture est nécessaire !

[Paul TOTH]

Peux tu être plus clair s'il te plaît ?

l'aide dit....
Par conséquent, ShowModal ne renvoie rien avant la fermeture de la fiche. Lorsque la fiche se ferme, elle renvoie la valeur de la propriété ModalResult.

jusque là je suis d'accord, ça veux dire que le code qui suis le ShowModal ne s'execureta pas tant que la fiche modale est affichée.

Le lien renvoi sur un exemple qui se base sur la valeur du showmodal donc du ModalResult or les conseils données ne l'utilisent pas puisque sa valeur peut être fausse... car le Modalresult appartient à la fiche qui est affichée par le showmodal ? et si on ne doit pas récupérer les valeurs après le showmodal....

la valeur retournée par ShowModal qui provient de ModalResult. Donc même si la fiche est supprimée, on peut tester la valeur de ShowModal !

D'autre part, la fiche n'est détruite QUE SI on lui donne un caFree dans l'évènement OnClose

Code :

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

1
2
3
4
5
 
procedure TForm2.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
  CanClose := caFree;
end;

mais comme expliqué avant, si on fait ça sans mettre à nil la variable de la fiche, c'est le Form2.Free qui va planter puisque le pointeur n'est pas nil mais l'instance a été détruite.

Or donc la pratique courante est de ne pas indiquer caFree dans OnClose et de lire les membres de la fiche avant de la détruire.

Code :

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

1
2
3
4
5
6
7
8
 
  with TForm2.Create(nil) do
  try
    if ShowModal = mrOK then
     ...
  finally
    Free
  end;

SI, et seulement SI, tu mets un caFree,il ne faut pas détruire la fiche, et on ne peux pas lire ses membre en sortie de ShowModal car la fiche est alors détruite.

et il n'y a aucun sombre bug de Borland là dedans.

[tourlourou]

Si je lis bien l'anglais, il est en résumé exclusivement recommandé de de ne pas accéder aux membres d'une fiche modale qui aurait été libérée. (Ce n'est d'ailleurs pas spécifique : il n'est jamais indiqué d'adresser un objet libéré !)
Cet avertissement ne semble lié qu'au fait qu'une fiche modale ait pu être libérée automatiquement. ( Action:=caFree; )

Je déduis que cet avertissement ne concernerait que l'utilisateur de fiches modales qui ignorerait leur code (détruite ou pas ?).
Mais comme la parade nécessite de modifier leur code, ce n'est possible que si on le connaît...
Donc cet avertissement n'est pas pertinent pour peu que l’utilisateur se serve de code dont il sait ce qu'il fait !

[jovanovic.radoslav]

tourlourou resume bien ce qui est dit, d'ailleurs on peut aussi trouver la même page en français.

A ma connaissance la construction d'une fenêtre en vue de son affichage par showmodal n'a rien de spécial.
On ne parle pas du caFree, ni caHide, la propriété fsModal n'est pas publié c'est une fenêtre comme une autre.
POURQUOI les recommandations ne sont pas données dans les infos d'un TForm ? Cela aurait été aussi utile.

On sait bien que si l'instance d'un objet est liberée on ne doit pas y accéder.
POURQUOI nous le dire spécialement sur la fonction ShowModal ?


Andnotor
Tes certitudes t'empêchent de réfléchir (ne prend pas cela comme une insulte, y'a seulement que tu dégaines trop vite)

Tu dis :
"Le Result renvoyé par ShowModal ne peut pas être faux ???? " mais nous ne sommes pas dans le cas d'une fonction qui a un comportement normal avec une fiche...

Si on se base sur les recommandations données dans l'aide le Result renvoyé par ShowModal peut ne pas être exact.

Tu as raison quand tu dis : Ce qu'on aimerait surtout c'est d'avoir le lien sur une page officielle Embarcadero disant spécifiquement "Les propriétés d'une fiche peuvent être (sont) indéterminées au retour de ShowModal".

Mais il y a peut-être des raisons stratégiques pour ne pas le faire ou le dire ainsi. Donner les recommandations est une façon détournée de le faire.


Paul TOTH
Tu restes trop axé sur le code que nous (programmeurs) écrivons. Le problème n'est pas dans notre code mais dans le code écrit par Borland au niveau du changement du ModalResult.


Je suis un peu déçu que vous ne soyez pas tombé de votre chaise en lisant le passage REPONSE et CONCEQUENCES ou alors personne ne l'a lu...

Je mets en rouge les parties qui sont à l'origine du problème.

Je les reprends (informations que j'ai eu à l'époque) :


REPONSE : enfin pour comprendre pourquoi on doit suivre les recommandations Embarcadero sur la façon de récupérer les données provenant d'une fenêtre affichée par ShowModal, sachez que suite à une erreur (?) de programmation chez Borland lors de l'écriture du code gérant le ModalResult d'une fenêtre affichée par Showmodal, le programmeur a fait appel à une fonction qui informe le système d'exploitation que la mémoire allouée càd celle de mafiche2 est à la disposition du système d'exploitation (donc IMMEDIATEMENT).

CONSEQUENCES : le système d'exploitation peut écrire (IMMEDIATEMENT) dans la zone mémoire que le programmeur (càd nous) n'a pas encore libérée (c'est pour cela que je me demande si le free est bien utile dans ce cas ?).
Et donc toutes les données récupérées, après le Showmodal, peuvent être erronées.

CELA VOUS PARAIT NORMAL QUE LE SYSTEME D'EXPLOITATION PUISSE ECRIRE DANS LA ZONE MEMOIRE QUE VOUS N'AVEZ PAS ENCORE LIBEREE.

A moi non !!!

[Paul TOTH]

suite à une erreur (?) de programmation chez Borland lors de l'écriture du code gérant le ModalResult d'une fenêtre affichée par Showmodal, le programmeur a fait appel à une fonction qui informe le système d'exploitation que la mémoire allouée càd celle de mafiche2 est à la disposition du système d'exploitation (donc IMMEDIATEMENT).

le code de ShowModal est disponible, il a été donné en parti ci-dessus et il ne contient aucun appel système mystérieux, maintenant, si tu ne veux pas l'entendre...tu peux continuer à crier au loup...

[tourlourou]

Si la fiche B est toujours en mémoire, il est possible de l'interroger via ses propriétés et ses fonctions membres tout comme les fiches non modales de l'exemple précédent.

Dixit Embarcadero. Il n'y a donc pas de problème particulier aux fiches modales. Et il est inutile de proposer dans l'aide un exemple qui permette de s'affranchir de la maîtrise du cycle de vie de la fiche modale dans la mesure où il faut le respecter pour tous les autres objets !

[Andnotor]

Si on se base sur les recommandations données dans l'aide le Result renvoyé par ShowModal peut ne pas être exact.

Alors pourquoi l'utilises-tu ? (TFrmGestionCollections.Execute)

Et pourquoi cette information capitale ne figure-t-elle pas sur ton site ?

[jovanovic.radoslav]

Andnotor

Parce que c'est dans le Onclosequery de la fiche qui est affichée en ShowModal, et non à l'extérieur de celle-ci. Les recommandations sont de ne pas l'utiliser à l'extérieur.

Quand j'ai écrit ce code je ne savais pas qu'il y avait aussi peu de programmeurs à ne pas connaître ou ne pas utiliser les recommandations. Il n'y a pas besoin d'information supplémentaire puisque' il y a l'exemple....

Je place un exemple modal.rar de la méthode que j'utilise. Je pense que cette méthode respecte les recommandations de l'éditeur. Tant que les recommandations seront présentes, je ne prendrai pas le risque de faire autrement.

[Andnotor]

Execute !!!

Code :

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

1
2
3
4
5
6
7
8
9
10
11
function TFrmGestionCollections.Execute(Value: Pointer): TModalResult;
begin
  try
    NomCollection := Value;
    if assigned(NomCollection) then
      CmbBxCollections.Text := String(NomCollection^);
    Result := ShowModal;
  except
    Raise Exception.Create('EXCEPTION dans TFrmGestionCollections.Execute');
  end;
end;

Il n'y a pas besoin d'information supplémentaire puisque' il y a l'exemple....

Mais pourquoi n'y avais-je pas pensé ?!? C'est tellement logique...