Discussion :

[adurandet]

Bonjour,

voici mon probleme :

j'ai un application avec 6 TForm.

Une premiere qui s'appelle TAccueil sert d'ecran principal et gere l'affache des autres qui sont, aux démarage de l'appli jsute disponible et non créer.

j'ai au debut utilisé :

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
new FormTruc;
if (mrOk == FormTruc->ShowModal()) 
{
  //faire qqchose sinon faire autre chose...
  delete FormTruc;
  new FormMachin;
  if (mrOk == FormTruc->ShowModal()) 
  {
     //etc....
  }
  else
  {
  }
}
else
{
  faire autre chose
}

Mais c'etait trop contraignant car il faut prevoir toutes les possibilités de passage d'une fenetre a une autre.

je me suis donc dis j'ai jsute a faire

Code :

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

1
2
new FormMachin
FormMachin->Show

et quand je quitte ma fenetre FormMachin je fais :

Code :

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

1
2
3
4
 
new FormTruc
FormTruc->Show();
delete this //pour delete la fenetre créer pécédement

mais j'ai l'impression que cette deuxieme solution pause des problemes au niveau des deletes car j'ai des erreurs aleatoire qui apparaisse quand j'utilise mon application.


Qu'en pensez vous ?

Avez vous une autre solution ?


de votre aide

[ac_wingless]

Les fenêtres prennent en général peu de ressources, donc on peut créer toutes les fenêtres au lancement de l'application, et les afficher uniquement si besoin.

exemple:

Code :

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

1
2
3
4
5
6
7
8
 
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
	try
	{
		Application->CreateForm(__classid(TFormBlaBla), &FormBlaBla);
		Application->CreateForm(__classid(TFormBluBlu), &FormBluBlu);
		...

ensuite, on affiche les fenêtres simplement avec ShowModal ou Show, selon le besoin:

Code :

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

if ( FormBlaBla->ShowModal() == mrOk )...

On peut attribuer certaines valeurs à des boutons pour qu'ils ferment automatiquement la fenêtre en renvoyant mrOK ou mrCancel.
Avec cette méthode, pas de souci avec new / delete.

Il est bien sûr tout-à-fait faisable de créer des fenêtres par new / delete, et c'est même recommandé pour ne pas immobiliser de la mémoire dans des fenêtres non visibles. Cependant, cela demande de la rigueur comme pour toute gestion de pointeur: il faut "suivre" ses allocations avec précision, et pas seulement saupoudrer des new / delete un peu partout, ce qui n'est pas forcément simple si on trouve déjà qu'il est trop compliqué de repérer tous les enchainements d'une fenêtre à l'autre. Mais en tout cas, "delete this;" devrait lever un méga gros drapeau rouge

Je vais donc me faire l'avocat du diable: plutôt que d'apprendre la gestion des pointeurs dans le cadre d'une appli vite fait, mieux vaut peut-être mettre la poussière sous le tapis en suivant la méthode que j'indique, avec création au début de l'application, et affichage au besoin.

[adurandet]

effectuivement le delete this est pas mal. Je pensais qu'un objet pouvait s'auto detruire

ce qui n'est pas forcément simple si on trouve déjà qu'il est trop compliqué de repérer tous les enchainements d'une fenêtre à l'autre

c'est pas que je trouve compliqué de repérer les enchainements de fenêtre c'est jsute que ca fait enormement de brique pour l'utilisation de ShowModal() et le code devient vite illisible.


je n'ai pas trop envie de juste les cacher, je vais reflechir et trouver une solution pour "deleter" les fenetres.


D'ailleurs j'ai une question :

est ce que seul le proprietaire d'un objet peut detruire celui ci ?

si par exemlpe :

A créer B
B cache A
B créer C

est ce que C peut detruire B ?

de vos réponses

[ac_wingless]

Un objet peut très bien s'autodétruire, et "delete this" est en théorie tout à fait utilisable ... si on sait ce qu'on fait. Il y a très peu d'utilisations légitimes (d'où ma mention de drapeau rouge), car normalement le créateur a l'opportunité de détruire.
Cela ne semble pas être ton approche (A crée B qui crée C qui détruit B...).

Les trapézistes de cirque n'ont pas besoin d'avertissements "Ne pas se pencher par la fenêtre". Si on est capable de gérer correctement un schéma de création / destruction complexe comme celui que tu exposes, alors on peut faire des montages acrobatiques, y compris avec delete this... mais en général, on n'a pas besoin de conseils si on est déjà à ce stade de maitrise. Ce qui ne veut pas dire de toute façon que ce soit une pratique recommandable! Je persiste à penser qu'une gestion new / delete de fenêtres devrait se faire non pas de façon ad hoc comme dans l'exemple A/B/C/B ci-dessus, mais ponctuellement autour de l'affichage, c'est à dire avec une séquence {création, affichage modal, destruction}. Ceci peut s'implémenter en une seule fonction courte avec des templates <T>, en utilisant __classid(T) et en manipulant pour ShowXXX et delete un pointeur de la classe de base TForm.

Pour un schéma acrobatique comme celui proposé, c'est un exercice en soi, pas vraiment lié aux fenêtres d'ailleurs. Le plus gros souci est que les variables qui devront stocker les résultats de "new" pour réutilisation future par delete devront être extérieures au scope de la partie de code qui crée, donc par exemple des variables globales, ce qui est une très mauvaise pratique (et si l'tutilisateur boucle en rond sur une série de fenêtres? on fait des piles globales?).

Je suggère de ne pas mélanger les problèmes, et d'adopter la méthode simple ci-dessus (Show et Hide ne peut pas crasher si on affiche ou cache plusieurs fois de suite). Par ailleurs, pour s'entraîner avec new / delete dans des situations acrobatiques, ne serait-ce que pour expérimenter en vrai pourquoi c'est si peu recommandé, il suffit de faire un petit programme affichant sur la console des variables new float...
Petite indication: avec new et delete, il n'y a pas de "propriétaire" d'un objet au sens des composants VCL. Le résultat de new doit être conservé de manière à être accessible plus tard par delete, et n'importe qui peut y accéder, devenant ainsi temporairement le "propriétaire" aux fins de destruction... sauf si la durée de vie ou les droits d'accès de ce stockage sont trop faibles pour le code destructeur. Attention donc au stockage sur la pile (variables locales), dans des zones privées, etc.

Bon courage.

[adurandet]

merci pour ta reponse.

J'ai finalement fait un systeme de new/ show modal/ delete comme tu le disais plus haut.

Tout a l'air de tres bien marché.

merci à toi

cordialement