Gestion des FORM

Salut à tous j'ai un petit problème.

J'ai un simple programme mon premier et donc pour bien tout prendre en main j'ai une FROM 0 (principale) avec un button 1 + un event on_click.
Qui me permet d’ouvrir une seconde FROM N(2).
Sa marche la première fois mais si je ferme cette FROM 2. Lors d'un second click que le btn j'ai une erreur et ma fenêtre ne s'ouvre pas..

Une idée de régler le problème ?

Merci.

Lorsque tu fermes ta seconde form par la croix rouge, par exemple, elle disparaît de l'écran, mais elle existe toujours ! Tu peux le vérifier par

Code:: IF OBJECT_EXISTS(numero_de_form%)=1
SHOW numero_de_form%
ELSE
FORM numero_de_form%
...
END_IF

Tu vois le principe ?

Oui oui je vois le truc.

Pour mon code il se présente comme cela :

Code:: rem Bouton pour gerer le configuration, puis enregistré dans un fichier.devi)
button 14
left 14,400
top 14,1
width 14, 100
caption 14,"Configuration"
on_click 14,set_conf

rem et mon sous programme set_conf

set_conf:
form 15
left 15,0
top 15,0
width 15,550
height 15,492
caption 15,"Configuration général"

button 16
left 16,1
top 16,1
width 16, 150
caption 16,"Mettre à jour"
parent 16,15
on_click 16, save_conf

memo 17
left 17,1
top 17,35
width 17,530
height 17, 350
parent 17,15
file_load 17, "C:\Users\demenvil\Desktop\D3VY\conf.general.devi"
return

save_conf:
file_save 17,"C:\Users\demenvil\Desktop\D3VY\conf.general.devi"
message "Configuration mise à jours avec succès !"
message "Pensez à redémarrer D3VY pour que la configuration soit prise en compte"
return

Cet action ferme donc la form 15 créer par le sous programme set_conf.

Le truc est : Est ce qu'il est mieux de "pré-créé" les form que je veux leur mettre un HIDE et un show au clique sur le bouton puis de nouveau un HIDE ?

Ne peut-on pas créer la form au clique et le détruire à la sav du fichier de conf. et refaire cette action si il y a un nouveau clique ?

Merci.

Tu as peut-être remarqué qu'à la création de n'importe quel objet, celui-ci s'affiche brièvement e, haut à gauche de l'écran. Ceci peut conduir à un scintillement désagréable.

Pour ma part, je crée toujours toutes les FORM annexes en début du programme, en mettant HIDE tout de suite, avant même de leur ajouter leurs objets. Ensuite, je travaille avec SHOW et HIDE pour gérer leur présence à l'écran.

Mais tu aussi supprimer une form si tu n'en as plus besoin. Le problème, c'est que techniquement, tu ne peux absolument pas le faire dans un traitement qui a été initialisé par la form que tu veux supprimer, comme un bouton de fermeture, par exemple. Cela conduit à un crash, car dans ce cas, l'adresse de retour du sous-programme n'existe plus si la FORM est supprimée.

Il est donc techniquement beaucoup plus simple (et plus sûr) de tout créer au début.

Ok ok alors je vais modifier mon code et créer toutes mes form au début et je met un HIDE puis je vais jouer avec les condition pour les gérer.
Et donc de cette manière je vais pouvoir si je le veux ouvir x fois une form et la fermer ?

En effet. Le fait de fermer une form par la croix rouge est très similaire au résultat de la commande HIDE. La seule vraie différence, c'est que la routine ON_CLOSE de la form (si elle a été demandée) n'est pas exécutée par HIDE, mais uniquement par un clic sur la croix rouge. Mais dans tous les cas, la form continue d'exister en état "chaché". ca va même plus loin: lorsque tu la rappelles par SHOW, le contenu de ses objets (EDIT, MEMO, COMBO, ...) est toujours intact !

Juste pour compléter l'info: si jamais tu veux vraiment supprimer une form, cela se par de la manière suivante:
DELETE numero_de_form%
Et tous les objets de la form seront supprimés automatiquement, avec bien sûr la perte de leur contenu.

J'ai essayer ce que tu me conseillé de jouer avec les hide et show mais cela ne semble pas fonctionner..
Aurais tu un exemple à me donner ?

genre form0 + btn 1 qui ouvre form 2 avec btn 2 qui la ferme ou alors la croix rouge.

et si je re-clique sur btn1 from 2 s'ouvre à nouveau.

Moi je me retouvre avec une erreur comme celle ci :

Code:: (62) Object already Defined :line 208..

Merci

Eh bien, regarde ceci:

Code:: label fermer_1, fermer_2, ouvrir_1, ouvrir_2

dim n_form1%, n_form2%
dim no%, no_form1%, no_form2%
dim visible_1%, visible_2%

caption 0,"Form 0"

no% = no% + 1 : form no% : hide no% : no_form1% = no%
top no%,100 : left no%,50 : caption no%,"Form 1"
command_target_is no% : ' les objets suivants seront créés pour cette form

no% = no% + 1 : button no% : top no%,30 : left no%,10 : caption no%,"Fermer"
on_click no%,fermer_1

no% = no% + 1 : form no% : hide no% : no_form2% = no%
top no%,140 : left no%,80 : caption no%,"Form 2"
command_target_is no% : ' les objets suivants seront créés pour cette form

no% = no% + 1 : button no% : top no%,30 : left no%,10 : caption no%,"Fermer"
on_click no%,fermer_2

command_target_is 0 : ' les objets suivants seront créés sur la form 0

no% = no% + 1 : button no% : top no%,10 : left no%,10 : caption no%,"Form 1"
on_click no%,ouvrir_1

no% = no% + 1 : button no% : top no%,10 : left no%,210 : caption no%,"Form 2"
on_click no%,ouvrir_2

end

ouvrir_1:
if visible_2%=1 then to_foreground no_form2%
show no_form1%
visible_1% = 1
return

ouvrir_2:
if visible_1%=1 then to_foreground no_form1%
show no_form2%
visible_2% = 1
return

fermer_1:
if visible_2%=1 then to_foreground no_form2%
hide no_form1%
visible_1% = 0
return

fermer_2:
if visible_1%=1 then to_foreground no_form1%
hide no_form2%
visible_2% = 0
return

Tu peux appeler l'une ou l'autre des deux forms, et la fermer, et même appeler les deux sans en fermer une...
Les commandes TO_FOREGROUND servent à garder les petites fenêtres fille devant la fenêtre principale, même si l'on clique sur un des boutons de la form principale, car celle-ci deviendrait alors la form active et cacherait la ou les autres.

J'ai une question pourquoi nommer les objets par un entier avec une incrémentation ?
je trouve que c'est moins lisible de faire chaque fois la même opéation

Code:: no% = no% +1

N'est-il pas préférable de les nommé comme on veux ? par exemple par module du programme ??

de 100 en 100 ce qui nous laisse une marge de 99 objet par module ?
et peut être donc de fragmenter son programme avec des INLCUDE ?

Je vais essayer ta méthode Smile

Merci à toi.

C'est vrai: ce n'est pas très lisible. Et c'est pour ça que j'ai défini deux variables: no_form1% et no_form2%. Elles contiennent les numéros des deux forms, quelque soient ces numéros.

Bien sûr, ceci est juste un petit bout de code pour montrer un détail précis.

Mais imagine une application complète, avec plusieurs forms, chacune ayant plein d'objets. En plus, dans Panoramic, il y a des objets non visuels, comme des DLIST, des TIMER, OPEN_DIALOG etc. Maintenant, admettons que ton application soit bien ficelée, opérationnelle. Tu as affecté des plages de numéros pour regrouper tous ces objets.

Maintenant, tu as besoin de modifier ton programme, en ajoutant par exemple quelques objets à une form. Et là, galère si la plage de numéros réservés ne te laisse pas la possibilité de le faire ! Il faut tout renuméroter...

Avec ma technique, tu insères un objet où tu veux, cela ne dérange rien, ne décale rien. Le numéros des objets dont on a vraiment besoin, on les copie dans des variables dont le nom si possible parlant donne une indication précise sur l'utilité de l'objet/ Un exemple: no_numero_de_client% contiendrait le numéro du champ EDIT dans lequel on saisit le numéro de client. Et c'est préfixé par no% no_ pour bien montrer qu'il s'agit d'un numéro de zone en non du numéro de client proprement-dit.

D'ailleurs, j'utilise depuis un certain temps une structure particulière qui permet de mieux structurer un programme Panoramic et de le maintenir plus facilement. Je fais comme ceci:

Code:: ' nom_du_programme_source.bas

label labels : gosub labels
gosub constantes
gosub variables
gosub donnees
gosub form0
gosub menu
gosub GUI
gosub initialisations
end

labels:
label constantes, variables, donnees, form0
label menu, GUI, initialisations
' ... ici, les autres labels de l'application
label nouveau_fichier,sortir

return

' toutes les variables qui sont en réalité des constantes
constantes:
dim rep$ : rep$ = "C:\MonDossier\"
' ... ici, toutes les autres "constantes"
return

' toutes les vraies variables
variables:
dim no%, no1%, no2%, i%
' ... ici, toutes les autres variables
dim no_open%, no_numero_client%
return

' toutes les commandes DATA qui seront utilisées par READ
donnees:
' ... ici, toutes les commandes DATA xxx
return

' paramétrage de la form 0
form0:
caption 0,"Mon application"
' ... autres paramétrages de la form 0
return

' définition du menu de l'application
menu:
no% = no% + 1 : main_menu no% : no1% = no%

no% = no% + 1 : sub_menu no% : no2% = no% : parent no%,no1%
caption no%,"Fichier"
no% = no% + 1 : sub_menu no% : parent no%,no2%
caption no%,"Nouveau" : on_click no%,nouveau_fichier
no% = no% + 1 : sub_menu no% : parent no%,no2%
caption no%,"---------"
no% = no% + 1 : sub_menu no% : parent no%,no2%
caption no%,"Sortie" : on_click no%,sortir

no% = no% + 1 : sub_menu no% : no2% = no% : parent no%,no1%
caption no%,"?"
no% = no% + 1 : sub_menu no% : parent no%,no2%
caption no%,"Aide" : ' ...etc

return

' configuration de l'interface visuel
GUI:
' d'abord, tous les objets non_visuels
' exemple:
no% = no% + 1 : open_dialog no% : no_open% = no%
filter no%,"Mes fichiers|*.dat;*.xxx"

' ensuite, les objets de la form 0
no% = no% + 1 : alpha no% : top no%,10 : left no%,10
caption no%,"Numéro client"
no% = no% + 1 : edit no% : top no%,10 : left no%,100
no_numero_client% = no%
' ... tous les autres objets...

return

initialisations:
if dir_exists(rep$)=0 then dir_make rep$
' ... toutes les autres initialisations
return

' ********** routines évènements des objets

nouveau_fichier:
message "Choix: nouveau fichier"
return

sortir:
if message_confirmation_yes_no("Voulez-vous vraiment sortir ?")=1 then terminate
return

Voilà, c'est ma technique. Tout est modulaire. On insère ou on enlève des objets, sans conséquence pour le reste. Mais bien entendu, je te poste cela uniquement comme un exemple de structuration. Chacun a sa manière d'écrire et ma méthode est adaptée à ma façon personnelle de voir les choses.
V

Oui c'est pas mal comme technique aussi : )
Pour la modularité c'est pour sa que je nome de 100 en 100.
ensuite mon code également et structuré un peu de cette manière.

Les menu avec les menu, form avec les form, etc etc..

bonjour,
Au sujet de la création de FORM, faites cet essai :

Code:: LABEL CreateForm
BUTTON 1:CAPTION 1,"Go !"

ON_CLICK 1,CreateForm
END

CreateForm:
IF LABEL("DeleteForm")=0 THEN LABEL DeleteForm
FORM 2
BUTTON 3:PARENT 3,2:CAPTION 3,"Quitter"
ON_CLICK 3,DeleteForm
ON_CLOSE 2,DeleteForm
RETURN

DeleteForm:
OFF_CLICK 3:DELETE 3
DELETE 2
RETURN

Klaus va me dire : STOOOOP ! tu détruis le FORM 2 alors qu'on est en train de traiter un evenement d'un de ces fils (BUTTON 3)... Ok mais:
La 1ere fois que l'on cliques sur "Quitter" on a bien un message d'erreur:
"Access violation...."
Mais le programme n'est pas arrêté !
Si on re-clique sur "Go!", le form 2 s'ouvre et l'appui sur "quitter" ne provoque plus de message d'erreur....

A noter que si la 1ere fois, on ferme form 2 par la croix, on n'a pas de message d'erreur...
scratch

Bonjour,
merci pour la contribution. Smile

Oui cela pourrait être une solution, une solution assez simple dans ton cas je pense se serai de pouvoir gérer l'affichage des erreurs.

En programmation on vois souvent ce genre d'option.

Soit on bloque tous, soit on affiche un certain type d'erreur choisie par des en-tête de fichier.
Je vais aller poster la suggestion, sa serai un plus.

Car mettre en prod avec un programme qui pour x raisons peut afficher des erreurs c'est pas trop top je pense ^^

Bonjour Demenvil,

Ce qui est surtout gênant dans cet exemple, c'est qu'il n'a a pas de terminaison du prog après le message d'erreur...
Que je me fasse jeter ?...
Soit : j'ai pas le droit de détruire un objet pendant l'exécution d'une routine d’évènement du dit objet...
Mais:
- pourquoi le prog continu à tourner et pourquoi le message d'erreur n'apparait plus par la suite ?
- Pourquoi le fait de cliquer sur la croix, ne provoque pas d'erreur ?
pourtant avec le on_close, je me retrouve "presque" dans la même situation que par le on_click ? (après réflexion, cela devrait être même pire...)

Oui oui,
Après je ne peut te répondre car je ne connais encore que très peut panomaric et surtout son comportement Sad

Mais détruire un option pendant sont exécution ou traitement oui effectivement sa me parrait bizzare que ce soit possible.

Après si nous avons la liberté de le faire sans problème ^^
ET je pense en y réfléchissant là que on fait on ne peut pas ! Car tu as bel et bien une erreur "Access violation".
Donc si je ne me trompe pas celle ci ne vient pas pour le fun :p

Nardo26 a écrit:: Mais:
- pourquoi le prog continu à tourner et pourquoi le message d'erreur n'apparait plus par la suite ?

J’ai testé ce bout de code curieux. Suspect

La 1ere fois il y a une violation de l’innocente mémoire. Laughing

La 2eme fois, il semble qu'il n' y a plus de viol…ation, mais continuez et recliquez sur ‘go’ 2 autres fois et le message d’erreur est de retour !

Le code est curieux et le comportement du système ne l’est pas moins ! Exclamation

» FORM
» Form auf Form
» DIM?? Form>0
» Gestion de threads ?
» Questions à propos de FORM