En feuilletant deux formes

Question

Je me demande si je suis quelque chose qui pourrait être Faire des mauvais, bien qu'il me semble une solution très pratique ...

J'ai deux formes que l'utilisateur devra marcher à travers . L'utilisateur clique sur un bouton et form1 apparaît. L'utilisateur appuie sur OK et le second apparaît. L'utilisateur clique à nouveau sur OK et les écrans sont partis. Ou l'utilisateur clique sur Réessayer et l'écran revient au premier. Les deux écrans sont des tailles complètement différentes avec des informations différentes.

Alors je suis venu avec ce code:

Form1 := TForm1.Create(SharedData); 
    Form2 := TForm2.Create(SharedData); 
    repeat 
    ModalResult := Form1.ShowModal; 
    if (ModalResult = mrOK) then ModalResult := Form2.ShowModal; 
    until (ModalResult <> mrRetry); 
    Form1.Release; 
    Form2.Release; 

Je l'ai testé ce code et il semble fonctionner comme un charme. Dans ce code, SharedData est un objet qui contient des données manipulées par les deux formulaires. Je crée cet objet avant que les deux formes ne soient créées et quand ModalResult == mrOK, j'écris simplement les données dans la base de données.

Problème, bien que je pense que c'est une solution propre à gérer le renversement entre deux formes, je ne me souviens pas d'avoir jamais vu quelque chose comme cette construction avant. Bien sûr, je suis un génie. (Au moins, moi Ego me dit que je suis.) Mais y aurait-il quelque chose contre l'utilisation de ce morceau de code ou est-ce que ça va?

Answer 1

Si le code fait ce qu'il est censé faire, je pense que c'est bon. Je n'ai jamais rien vu de tel auparavant, mais c'est assez évident ce que ça fait ... ce qui dans mon livre est bien mieux que de suivre aveuglément le travail des autres. :-)

Answer 2

Je ne vois rien de mal avec le code. Je remets cependant en question le passage de SharedData au constructeur des deux formes. À moins que vous ayez substitué le constructeur (en utilisant reintroduce aussi), l'argument de TForm.Create() accepte un propriétaire; ce propriétaire est responsable de la libération des objets qu'il possède. Puisque vous les libérez vous-même, il n'est pas nécessaire d'assigner un propriétaire; il suffit de passer nil à l'appel de Create() pour éviter la surcharge de l'enregistrement de la référence, accéder à la liste des objets possédés lorsque l'on est libéré pour supprimer la référence, etc

De plus, Release est conçu pour être appelé depuis l'intérieur le gestionnaire d'événements du contrôle lui-même, comme dans un événement de clic sur un bouton. Il s'assure que tous les messages en attente sont traités avant que le contrôle ne soit réellement libéré, afin d'éviter les AVs. L'utiliser comme vous le faites à nouveau ajoute une surcharge inutile, car vous ne les utilisez pas dans un gestionnaire d'événements. Vous pouvez utiliser simplement Form1.Free; au lieu.

Pour clarifier l'utilisation de Release, il est utilisé dans le code du Formulaire lui-même. Par exemple, si vous avez un bouton sur le formulaire, et vous voulez que le clic de bouton afin d'obtenir le formulaire à être libéré, vous utilisez sortie:

procedure TForm1.Button1Click(Sender: TObject); 
begin 
    Self.Release; 
    Close; 
end; 

Ceci permet le bouton cliquez pour libérer la forme, mais fait en sorte que l'appel suivant à Fermer s'exécute en premier. Si vous utilisez Free au lieu de Release ci-dessus, vous pourriez finir par appeler Close sur un Form1 inexistant. (Il y a de fortes chances que ce soit OK, à cause de l'absurdité du code ci-dessus, le formulaire serait toujours en mémoire, mais une mauvaise idée.)