CIBUS en panne !

Bonjour à tous !
Depuis plusieurs mois que j’ai remarqué un bug aléatoire dans mon programme.
Parfois, un objet prenait la fonction d’un autre objet ! ! ? ?
Ainsi, un EDIT pouvait prendre la fonction d’un BUTTON et sa commande ON_CLICK !
Parfois j’étais une semaine, voire quinze jours sans avoir ce problème.
Lorsque le dysfonctionnement apparaissait, il suffisait de fermer le programme et de le relancer (F9 dans l’éditeur) pour que tout re-fonctionne.
J’ai changé d’ordinateur et de système d’exploitation sans que rien ne change.
Plus mon programme grossit, plus cette panne aléatoire devient fréquente.
Et voilà que j’ai réussi à la « figer ».
Dans mon WEBDAV, dans le répertoire BUG ! SOS !, j’ai mis l’ensemble des fichiers qui permettent de recréer l’anomalie.
« Mode d’emploi » pour constater le bug :
Après avoir téléchargé TOUS les fichiers du répertoire ci-dessus, lancez PANORAMIC EDITOR version 0.9.26i5.
Chargez le programme Cibus v54.bas
Exécutez-le (F9) : La page CIBUS apparaît.
Appuyez sur le bouton START : le menu principal apparaît.
Appuyez sur le bouton PRODUITS : la page des matières premières s’affiche.
Appuyez sur MENUS : la page des MENUS s’affiche.
Cliquez sur le mot CROISSANCE comme pour le modifier : c’est l’objet EDIT 27 ligne 1603
=> Aie !  Il a pris l’action et la fonction de l’objet BUTTON 21 de la ligne 1563
Sur la partie gauche de la fenêtre j’affiche avec un simple print le numéro de l’objet cliqué et en réponse j’ai 21 = ce n’est pas normal.
Fermez le programme.
Ajoutez une ligne vide dans le programme à l’endroit qui vous fait plaisir et la panne se sera déplacée à un autre objet.
Consultez également le fichier PDF, il pourra peut-être vous aider.

Ergonomie adoptée pour mon programme :
Menu principal : j’affiche les boutons 1 à 7 qui restent permanent d’un sous-menu à l’autre.
Quand je clique sur le sous-menu PRODUITS (BUTTON 1), je détruis tous les objets supérieurs à 19 et je crée les objets 20 à 132.
Quand je clique sur le sous-menu MENUS (BUTTON 2), je détruis tous les objets supérieurs à 19 pour créer de nouveaux objets, en l’occurrence 20 à 98.

Bug dans mon programme ou dans Panoramic ?

Merci de votre aide.

Marc

Avant même de télécharger ton projet et de le tester, j'ai une remarque à faire.

C'est la première fois que j'entends parler d'un tel problème, dans un programme Panoramic. Avec les précautions d'usage, j'ai tout de même tendance à penser qu'il s'agit un problème du programme et non de Panoramic. Un objet ne peut absolument pas prendre la fonction d'un autre. Il y a forcément un problème de numéro d'objet mal calculé ou établi lors de la création ou configuration d'un des objets au-delà de 19.

Une suggestion: insère ceci, juste devant la ligne qui met le problème en évidence:

Code:

message "Type d'objet: "+str$(object_type(x))

avec x étant le numéro de l'objet qui semble causer le problème (ayant pris la fonction d'un autre). En fonction de la valeur affichée, tu verras bien pour quel objet il se prend...

Je pense que tu devrait adopter la numérotation des objets en amont
type :

dim Objet% : no%=no%+1 : Objet%=no%

Les objets prennent un nom significatif comme numéro et le numéro est affecté
même si tu delete un objet, il suffit de le re-déclarer avec le nom de sa variable numéro.

Dans ton ancien post, tu disais effacer les objets et les reconstruire...  
Bref, j' ai repris un peu ton interface ( pour m' amuser )
Télécharge ce dossier :Ici

C' est juste une ébauche, si cela te plait, c' est cadeau 

Bonjour Klaus et ygeronimi,

J'ai mis la ligne : message "Type d'objet: "+str$(object_type(x))

Dès que j'ai cliqué l'objet, la fenêtre message me retourne l'objet 0.




ygeronimi, je vais regarder ce que tu m'as envoyé,

Merci de votre aide.

Heu...y a un souci, il n' y a pas d' object_type 0
tu as d' ailleurs du le voir dans la liste des types d' objet.

Marc37 a écrit:

Parfois, un objet prenait la fonction d’un autre objet ! ! ? ?
Ainsi, un EDIT pouvait prendre la fonction d’un BUTTON et sa commande ON_CLICK !

Comme ce comportement est, le moins que l'on puisse dire,  bizarre et comme écrivait Klaus : " Un objet ne peut absolument pas prendre la fonction d'un autre. Il y a forcément un problème de numéro d'objet mal calculé ou établi lors de la création ou configuration d'un des objets au-delà de 19. " , j'ai analysé un peu ton code :

Comme dans 99.99% des cas l'erreur se trouve entre la chaise et le clavier.


Tu définis les objets suivants :
Les objets 20 à 132 sont définis de la ligne 305 à la ligne 1203
L’objet 20 est un alpha  à la ligne 305 etc …
Ligne 305

Code:

ALPHA 20
      font_size 20, 16
      LEFT 20,305
      TOP 20, 40
      CAPTION 20, "Entrées / Sorties / Caractéristiques matières premières"

   ' 1 ere colonne NOM DU PRODUIT
   EDIT 21
      LEFT 21,150
      WIDTH 21, 120
      TOP 21,142
      HEIGHT 21, 30
      TEXT 21, pr$(0)
      ON_CHANGE 21, SaisieProduit

   EDIT 22
      LEFT 22,150
      WIDTH 22, 120
      TOP 22, 187
      HEIGHT 22, 30
      TEXT 22, pr$(1)
      on_change 22, SaisieProduit
etc …. Jusqu’à la ligne 1203 ALPHA 132

Puis, à partir de la ligne 1556 et jusqu’à la ligne 2105     , tu redéfinis d’autres objets avec les mêmes numéros !!!!!
Ligne 1556

Code:

BUTTON 20
        LEFT 20, 140
        TOP 20, 21
        WIDTH 20, 100
        HEIGHT 20, 45
        CAPTION 20, "Menu 1"

     BUTTON 21
        LEFT 21,285
        TOP 21, 21
        WIDTH 21, 100
        HEIGHT 21, 45
        CAPTION 21, "Menu 2


Etc ….. jusqu’ à  ligne 2105 ALPHA 98

Dans ces deux séries de définitions : des objets  différents et ayant les mêmes numéros !

C’est de là que vient tous les problèmes que tu rencontres.

Non Papydall !

Les objets crées en ligne 305 à 1203 ont été détruits avant que les objets des lignes 1556 à 2105 ne soient créées.

D'autre part, il est impossible de recréer un objet ayant un numéro déjà occupé sans que Panoramic nous renvoie l'erreur
"OBJECT already defined".

Edit : D'autre part, le fait d'ajouter une ligne vide dans le programme ne suffirait pas à supprimer ou déplacer le problème.

Désolé, l'erreur ne vient pas de là.

2ème edit :

Structure du programme :

Lignes 1 à 202 : initialisation des variables, déclaration des LABEL
Lignes 204 à 212 : création FORM 0
Ligne 214 : GOSUB Ecran_initial  =>  lignes 6018 à 6280
               Ligne 6280 : retour à la ligne 215
Lignes 215 à 281 : création menu principal => BUTTON latéraux de 1 à 7.
Ligne 281 : END

Puis arrivent les 7 sous-menus :

Matieres_Premieres => lignes 283 à 1427
                                Objets 20 à 132

Caracteristiques_Menus => lignes 1429 à 2378
                                     Objets 20 à 98

Courbes_De_Croissance => lignes 2380 à 3044
                                    Objets 20 à 81

Inventaire_Ration => lignes 3046 à 4179
                             Objets 20 à 143

Distribution_auto => lignes 4181 à 4734
                            Objets 20 à 82

Commandes_depart_Manuel => lignes 4920 à 5782
                                           Objets 20 à 53
                                           Objets 200 à 217

Parametre_Systeme => lignes 5784 à 6012
                                Objets 20 à 38

Je réitère : Entre chaque passage d’un sous-menu à l’autre, les objets supérieurs à 19 sont détruits par la routine suivante :

Routine Efface_ecran : lignes 4705 à 4720

  Efface_ecran:
     TIMER_OFF_ALL
     CLS
     For i% = 20 to 199
        If object_exists(i%)=0 then exit_for
        delete i%
     NEXT i%

     For i% = 200 to 300
        If object_exists(i%)=0 then exit_for
        HIDE i%
     NEXT i%

  RETURN



Je serai intéressé de savoir si quelqu’un a pu constater l’anomalie que je rencontre ?

Merci encore de votre aide.

Marc

Bonjour Marc37 !

Je prends le train en marche...

As tu vérifié lorsque tu détruit ton EDIT 21 par exemple,
et que tu crée le BUTTON 21, de bien changer :
ON_CHANGE 21,..... pour gérer la bonne procédure pour le bouton.
Ou bien mettre OFF_CHANGE 21

C'est surement là qu'il y a un problème...

Le mieux c'est de créer tous les objets sur les differentes pages.
Il n'y a pas de limitation.

Comme cela tu n'aura pas de doublon.
Chaque objet aura son usage et sa procédure.

Bon courage pour la suite...

Bonjour Minibug,

Merci pour tes remarques.

J'avais déjà fait des essais et constaté que le fait de supprimer un objet
détruit également ses commandes ON_CLICK, ON_CHANGE etc.

Donc je ne pense pas que cela vienne de là.

A suivre ...

Marc

Je pense que c'est une piste à creuser quand même Marc37. Essayes de voir si en arrétant cette gestion d'événement proprement tu ne faits pas disparaitre le problème.
Si tu ne le faits pas, tu laisses le système dans un état 'instable' ce qui pourrait expliquer le comportement 'aléatoire' du problème.
Au pire ça prend quelques minutes à tester par rapport au temps que tu as dû passer à faire ton programme, je pense que c'est un investissement de temps interessant. De toute manière, ça te permet d'avoir un code plus "propre".
Tu désactives d'abord la gestion du clic, puis tu supprimes l'objet
Tu créés le nouveau et tu actives la gestion des événements.
Je ne te garantie pas que ça resoudras ton problème et ici au boulot, je ne peux pas tester, mais de la façon dont j'imagine comment Jack a dû le coder, je pense que ça ne peut être que mieux et ça ne fait qu'une instruction en plus par bouton ...
Tiens nous au courant

Bonjour,
Je ne peux pas passer du temps sur ton programme.
Pour ma part sur ce genre de problème, et je suis sure que e n'est pas Panoramic qui est en cause. J'ai conçu bien des programme "hors norme" et ce type d'erreur j'en ai jamais rencontré. Il est vrai aussi que d'une version à l'autre de panoramic, il peut y avoir des différences.

Pour ma part dans ce genre de problèmes car personellement j'en ai eu des tas, je procède ainsi: je créé un memo de controle. Si il n'y a pas la place sur l'écran je le mets sur une autre forme qu'il faut rendre accessible, soit en laissant dépasser, soit en ajoutant un bouton quelque part pour la mettre devant. Je créé une sub ou je rempli ce memo des informations qui se modifie, avec le n° de ligne. Je créé un objet , je le marque, avec tout ce qui concerne celui-ci: type, nom, et évennement. Ainsi j'ai une trace. Lorsque je vois un problème, je regarde en remontant dans ce memo, les lignes en rapport avec les évennements. Peut-être aussi si il y a une erreur qui ferme le programme, y mettre un appel avec on_error_goto, pour enregistrer ce memo et le regarder calmement ensuite.

Pour ma part avec panoramic, je pense que je vais finr par refvoir la numérotation. A chaque fois j'oublie, mais je voudrai mettre ces N° dans une liste, ainsi:

En prenant pout principe: no=no+1 : button no, on ne sais plus où on en est.
Je verrai plutôt la chose suivante, et cela fait un moment que j'y pense:

Code:

dim nu(1000),nu$(1000)
objet():button no:...
    ' peut-être un autre tableau: nu$(no)=str$(no) +" button ouvrir ->>ouvrir_fichier"
objet():edit no:...

avec une sub:

Code:

sub objet()
   no=no+1:nu(no)=no
end_sub

Ainsi à chaque endroit on peut avec un message, ou envoi dans un memo, savoir ce qu'on fait.
Lorsqu'on arrive à END, on fait une sub pour connaitre la numérotation des objets, et en la sauvegardant sans un list ou memo, retrouver le bon numéro.

Je sais lorsqu'on a un grand programme de déjà conçu, il est difficile de revenir en arrière pour changer de méthode, mais cela donne à réfléchir pour les programmes à venir.

Edit: j'ai été trop vite: je ferrais plutôt un appel à la sub de cette façon:
objet("button ouvrir ->ouvrir_fichier")
et sub objet(a$)
...

Je pense que l'erreur réside dans la routine de destructions des objets:

Routine Efface_ecran : lignes 4705 à 4720

Code:

Efface_ecran:
    TIMER_OFF_ALL
    CLS
    For i% = 20 to 199
       If object_exists(i%)=0 then exit_for
       delete i%
    NEXT i%

    For i% = 200 to 300
       If object_exists(i%)=0 then exit_for
       HIDE i%
    NEXT i%

 RETURN

J’ai une réserve sur ce code :
Tu testes l’existence d’un objet : s’il existe, tu le supprimes, OK
Mais s’il n’existe pas, EXIT_FOR ne teste plus le suivant et on sort de la boucle.
Et le suivant peut exister et ne sera pas deleté

Si tu veux, modifier le code comme ceci et tester :

Code:

Efface_ecran:
     TIMER_OFF_ALL
     CLS
     For i% = 20 to 199
        If object_exists(i%)= 1 then delete i%
     NEXT i%

     For i% = 200 to 300
        If object_exists(i%)= 1 then HIDE i%
     NEXT i%

  RETURN

Je viens de tester avec la modification de Efface_Ecran:

Et .....
Il me semble que ça marche.
Peux-tu confirmer ?

Bien vu Papydall

Merci Papydall,

Malheureusement ça ne marche pas. Problème identique.


Les numéros des objets sont contigus, il n'y a pas de "trou".

Ils sont bien tous effacés : j'ai ajouté une "pause 200" dans la boucle Efface_ecran : je vois bien chaque objet s'effacer.

Désolé de me répéter, mais de toute façon, il n'est pas possible de créer un objet dont le numéro existe déjà.

Bug où es-tu ?

J'ai passé le weekend à lire et relire mon programme. A faire plein d'essais... A vérifier le cheminement du programme pas à pas.
Je ne trouve pas l'erreur.

Tu ne pas pas dit ce que tu pensais de mon embryon d' interface...

Quoi que...si elle est si moche que çà...


Edit: Comme je manque d' idée neuve voici une micro-suite : ici

ygeronimi :

Ton interface est superbe ! Mais pardonne-moi, je préfère conserver la mienne.

... Et j'ai la rage de trouver où est mon bug !

Minibug et Jicehel :

J’ai fait ce que vous m’avez conseillé : j’ai fermé TOUTES les actions ON_CHANGE, ON_CLICK et ON_KEY_DOWN par OFF_CHANGE, OFF_CLICK et OFF_KEY_DOWN avant de détruire les objets. Malheureusement, le problème persiste !

Juste pour info, voici le code que j'ai inséré pour détruire toutes les actions :

Code:

FOR i% = 21 to 29
      OFF_Change i%
      NEXT i%

      FOR i% = 39 to 56
      OFF_CHANGE i%
      OFF_KEY_DOWN i%
      OFF_CLICK i%
      NEXT i%
      
      FOR i%= 66 to 74
      OFF_CHANGE i%
      OFF_KEY_DOWN i%
      OFF_CLICK i%
      NEXT i%

      FOR i%= 84 to 101
      OFF_CHANGE i%
      NEXT i%

      FOR i%= 102 to 110
      OFF_CLICK i%
      NEXT i%

      FOR i%= 66 to 74
      OFF_CLICK i%
      NEXT i%

 Marc37

Bon, ben..., je la remets dans ma culotte...

Bien voila ce que je pense.

En regardant ton programme j'ai constaté qu'il n'y avait aucune sub. J'ai donc pensé que je pouvais faire un teste avec mon vieux dégugeur que j'ai conçu avant que les subs existent ainsi que d'autres fonctions que tu utilises.

Mais j'ai un problème: je me retrouve avec celui-ci avec un message d'erreur de repeat. J'ai donc arrêté là, car j'ai bien des choses à faire.

Et puis je me suis souvenu d'avoir entrevu des TIMER. Je viens de jeter un oeil et là je crois que j'ai compris. Plus il y a d'événements dans un programme, plus il faut mettre un intervalle long. Un intervalle de 100 me parait bien court. Il faut à mon avis au moins 500 ici, et je ne sais pas si c'est pas un peu juste.

Je ne suis plus d’accord personnellement avec Klaus, concernant la construction et la destruction d'objets. J'ai pu constaté que plus il y a d'événements en cours (je ne crois pas que c'est le nombre d'objets, mais le nombre d'événements à prendre en compte. Ou alors ne mettre des on_click ou autre que pour l'utilité de tel partie du programme, pour mettre ensuite à off_click, et valider d'autres événements. A force d'avoir des tas d'événements en cours, j'ai vraiment l'impression qu'au bout d'un certain nombre, ça commence à déconner.

Essayes de voir si avec des temps plus longs, le phénomène disparait.

Sur un point je suis d'accord avec Cosmos70: la survenue d'un évènement timer lors d'opérations critiques que celles dont on parle ici, est avec certitude une source de problèmes. Il faut faire TIMER_OFF lorsqu'on traite certains passages, et TIMER_ON pour réactiver. Il faut de toutes façons faire cela de façon systématique dans la routine on_timer elle_même, mais également dans toutes les routines on_click, on_change etc.

Exact et si le traitement est plus long que le timer, les "retours" s'accumulent et peuvent donner des traitement bizzare.
Moi maintenant, je met mon timer principal au délai le plus court nécessaire (par exemple pour toi, si une seconde pour le timer est suffisant, tu peux mettre 1000 ou 900 si tu préfères) et dans ma boucle principal je traite les événements.
Par exemple si un événement doit se faire au bout de 30 secondes, je mettrais un compteur que j'incrémente et quand il vaut 30 (ou plus par sécurité) , je fais le traitement et je remet le compteur à 0.

Pareil dans mes boucles de traitement, en règle générale, je fait un timer_off et je refais un timer_on en fin de traitement.

Je viens de revoir. Des timer_off, il y en a et aussi des off_change. Je ne pense pas que ça vient de là.

Par contre je n'aurai pas pensé à coder dans cette ordre là:

Code:

     TIMER 54
      TIMER_INTERVAL 54, 100
      TIMER_ON 54
      ON_TIMER 54, AffichagePoids

Mais plus tôt:

Code:

     TIMER 54
      TIMER_INTERVAL 54, 100
      ON_TIMER 54, AffichagePoids
      TIMER_ON 54

Je ne sais pas si cela change quelque chose.

Je me souviens qu'on début, mais Jack là finalement compris, qu'il fallait mettre timer juste avant le END, sinon l'événement se déclenchait avnt d'avoir lu le reste des objets avant end. De ce côté là on est tranquille.

Je suis sûr que TIMER n'est pas en cause : je les ai mis en REM et le problème persiste.

Bonne chance pour la correction. Cela dit je suis certainement celui qui est le moins surpris. Plus d'une fois j'ai signalé des comportements curieux. Mais j'ai toujours eus des réponses inapropriées à mon sens. Bon moi je fais avec.

On veut toujours qu'on mette des programmes simples pour faire la démonstration. Malheureusement, il n'y a qu'avec des gros programmes qu'on rencontre ces problèmes.