En exclusivité : la vidéo du BUG CIBUS

Bonsoir à tous,

Merci de prendre 5 minutes pour regarder cette vidéo qui décrit en live
le bug.

N'oubliez pas de mettre du son !



A qui appartient le bug ? CIBUS ou PANORAMIC ?

Merci à tous pour votre aide.

Marc

Edit : je soupçonne un dépassement de pile (stack overflow) dans Panoramic...

Je viens de regarder ta production cinématographique.
Je crois que tu peux la classer dans la catégorie "Comédie dramatique".
Effectivement, il y a un    dans ton programme.

Perso je me sers d' un label commun pour tout les "click"

démo :

Clic:
   Clic%=number_click
   if clic%=MonObjet% : Instruction : end_if
return

de même pour les "change" et "double click".
Cela me permet par un simple "message" de connaitre l' objet cliqué et que le click soit bien redirigé.

Marc37 a écrit:

je soupçonne un dépassement de pile (stack overflow) dans Panoramic...

Je croix qu'un Stack overflow ou Stack underflow provoque en général un crash.
Pour ton programme, je penche (pense) pour un problème du à Panoramic

Code:

dim i

for i = 1 to 9999
    ' ici, je déclare un objet, par exemple BUTTON i ou LIST i
    Caption 0,str$(i)
    if scancode <> 0 then terminate
next i

' La boucle ne se termine pas :  message d'erreur : Out of memory
' Pour l'objet BUTTON i : à partir de : 5385
' Pour l'objet DLIST i  : à partir de : 5431
' Pour l'objet LIST i   : à partir de : 5360
' Pour l'objet ALPHA i  : à partir de : 5386

Si j’ajoute quelques lignes de REM dans la boucle, l’erreur Out of memory passe pour (LIST i) de 5360 à 5358 et (plus étrange encore) si j’ajoute une ligne vide, la valeur passe à 5362.

Bonjour Marc37 !

je viens de voir ta vidéo et là effectivement on comprends mieux le problème.

Vraiment étrange ce bug, car pour moi c'est un bug.
Mais bon, si Jack passe par là, il pourra peut être nous en dire d'avantage...

Salut à tous,

@Marc37,

Quelle version de Panoramic utilises-tu ? Il me semble que c'est la V.09.26i5.
Tu devrais essayer avec la V.09.25 pour voir si c'est pareil.
A essayer également: transformer une version "buggée" en exe pour voir ce que çà donne.

A+

Un truc que je ne comprends pas dans ton code, Marc37

La variable NM$(?) représente les noms des menus. Ors au label "Saisie_Nom_Menu:"
la saisie qui est testée se fait dans l'objet 27 qui est un édit de la page produit

Je crois bien que là il y a un souci !

A+

Puis-je faire une suggestion ?

Panoramic a des limites techniques suffisamment vastes pour ne pas avoir besoin de cette gymnastique de création/suppression permanente d'objets. Dans des situations similaires, je définis des plages de numéros d'objet pour chacune de ces "pages". Et je crée un objet PANEL pour chacune de ces pages, en plaçant tous les objets d'une même page dans le panel concerné. Exemple:
panel 1000 : hide 1000
alpha 1001 : parent 1001,1000 : ...
edit 1002 : parent 1002,1000 : ...
...
Il suffit alors de faire show 1000 pour afficher la page, et hide 1000 pour la cacher lors du passage à une autre page. Bien sûr, il fait créer toutes les pages du programme au début, et les cacher aussitôt, pour n'afficher que la page d'accueil.

Ainsi, on évite absolument tous les problèmes comme ceux rencontrés pas Marc37. Et la technique de Ygeronimi est redoutablement efficace: faire un seul label pour tous les on_click, et dans cette routine, détecter l'objet cliqué par une construction Select:
label_pour_les_clics:
select number_click
case 1004: traiter_click_sur_bouton_1004()
case 1017: traiter_click_sur_bouton_1017()
case 2003: traiter_click_sur_bouton_2003()
..?
end_select
...
sub traiter_click_sur_bouton_1004()
...
end_sub
sub traiter_click_sur_bouton_1017()
...
end_sub
sub traiter_click_sur_bouton_2003()
...
end_sub

Et même technique pour les on_change etc. Et n'y aura plus jamais de problème de ceux rencontrés par Marc37. En plus, à l'exécution, il y aura un gain de performance de de confort visuel notable.

Oui Klaus, cette méthode est surement la bonne pour Marc37.

Mais avant, Marc je pense que le problème est là:

Jean claude a écrit:

La variable NM$(?) représente les noms des menus. Ors au label "Saisie_Nom_Menu:"
la saisie qui est testée se fait dans l'objet 27 qui est un édit de la page produit ....

A+

Bonsoir à tous,

Merci de vos nombreuses réactions et conseils.

Je m'attelle à la restructuration de mon programme pour contourner ce bug.

@Jean Claude :
La version utilisée de Panoramic est la 0.9.26i5.
En version exe => même problème
Avec la version 0.9.25i9  => même problème

Jean Claude a écrit:

La variable NM$(?) représente les noms des menus. Ors au label "Saisie_Nom_Menu:"
la saisie qui est testée se fait dans l'objet 27 qui est un édit de la page produit ....

Non Jean-Claude, la variable NM$(x) est en relation avec l’objet EDIT 27 ligne 1603 et le test se fait dans la routine « Saisie_Nom_Menu » qui est ligne 2194. Le tout est bien dans le sous-menu « CARACTERISTIQUES_MENUS » qui commence en 1433 et se termine en 2378.

Au boulot ! Je commence et vous tiens au courant.

Ce que j'ais fait c'est de donner une couleur à l'objet 27, (COLOR 27,100,100,100) et quand on lance le programme l'édit en gris est bien sur la page des produits.
Donc je ne vois pas pourquoi au label "Saisie_Nom_Menu:" la saisie qui est testée se fait dans l'objet 27. ?
Une précision: j'ai fait le test à partir du fichier SOS.

A+

Bonjour Jean Claude,

Je viens de faire l'essai, tout est bon pour moi : l'objet 27 dans la partie PRODUITS reste bien blanc et l'objet 27 dans la partie MENUS est bien devenu gris.

Je pense que tu t'es trompé d'EDIT 27.

Il faut mettre ton "COLOR 27" dans le sous programme "Caracteristiques_Menus:" (sous-menu "MENUS")
L'objet 27 est créé à la ligne 1603.

Quant à l'EDIT 27 de la ligne 360, il fait partie du sous-programme "Matieres_Premieres:" (sous-menu "PRODUITS")

J'utilise 7 sous-menus et, lorsque je change de sous-menu, je détruis la page d'objets pour en recréer une nouvelle avec des nouveaux objets. Il est donc normal de retrouver, tout au long du programme, plusieurs fois des objets 27.

Mais c'est du passé !
Je suis en train d'attribuer un numéro d'objet unique à chaque champ. Je ne les détruirai plus, je les cacherai (HIDE).

En effet, ce sera plus facile à maintenir de toute façon.
Ton problème est peut être bien un bug de Panoramic, mais au moins tu aura vérifié tout les points sombres de ton programme et il sera au sortir de ce debuggage encore plus "propre" qu'avant.

C'est vrai que c'est assez difficile de travailler sur de gros programme (c'est là que les éditeurs de Klaus ou d'Ygeronimi prennent toute leur valeur) car soit on fait plein d'include pour garder des bouts clairs par thèmes, mais c'est lourd à débugguer par rapport au numéro de ligne. Soit on garde tout dans un programme et là, c'est lourd pour retrouver quelque chose surtout quand le bouton rechercher reste grisé ce qui arrive de temps à autre dans l'éditeur (en tout cas chez moi).

En tout cas, je crois les doigts pour que cette réécriture avec des objets par plages, affichés ou masqués résolvent ton problème et que le programme sera stable.

Maintenant, je comprends mieux.

Vu ce que tu dis, il y aurait un problème avec DELETE 27 (De ton code ou de Panoramic, je n'ai pas vérifié)

Tu fais bien de réorganiser ton code, car je n'ai pas le souvenir que DELETE N pose problème.
Personnellement je préfère nommé les objets avec des variables: du genre edit_nom_menu1% à la place de 27 et j'évite DELETE pour un objet qui devra reservir dans le programme.

Bon courage pour la suite.

A+

Il y a une autre possibilité que de "deleter" ou de remplir des tas d'objets.

Si et cela semble se présenter ainsi dans ce programme, il y a des choses communes dans la présentation, c'est d'avoir les objets de présentation, c'est à dire par exemple un EDIT que l'on définie dans un sous programme, avec son évennement, et lorsque c'est nécessaire, appeler un autre sous-programme avec une autre représentation et événement pour les mêmes objets. Cela a pour effet de limiter les objets, et surtout le nombre d'événements présent en même temps.

Si tous les événements sont déclarés à la fois comme ce sera surement le cas, là l'intervelle du timer aura certainement besoin d'être augmenté.

Bon j'arrète de donner des conseils, je sais même pas si je suis compréhensible dans ce que je dis.

Merci pour les suggestions.

Dans la version définitive, il n'y aura pas de TIMER. Il est implémenté actuellement juste pour faire les essais de pesée. Au final, ce sera une boucle qui prendra fin quand le poids demandé sera atteint.

Je modifie la numérotation des objets, ce qui me permettra de ne plus les détruire mais de les cacher (HIDE).
Dans un premier temps je reste sur la FORM 0 en espérant ne pas déclencher une nouvelle colère de Panoramic.

Si tout va bien, j'essaierai dans un second temps de suivre les conseils de Klaus, en utilisant un PANEL par sous-menu.

La route est longue, très longue ...

Je pense que tu es sur la bonne voie, Marc37. Certes, c'est lourd de tout reprendre. Mais le jeu en vaut la chandelle. Et l'avantage des Panels, c'est que tu caches tout le panel avec tous ces objets avec un seul HIDE, au lieu de faire un HIDE pour chacun des objets individuels de la "page".

Bonjour,
Tu peux aussi simplifier ton code lors de la declaration de tes objets avec des boucles FOR.
Par exemple j'ai pris un bout de code de ton prog:

Code:

Mask_Commandes_Depart_Manuel:
      ALPHA 200
         FONT_SIZE 200, 18
         LEFT 200, 400
         TOP 200, 30
         CAPTION 200, "Commandes départ manuel"
  
  ' ------------- 1ère colonne --------------------
    FOR i% = 1 TO 6
      BUTTON 200+i%
         LEFT 200+i%,205
         TOP 200+i%,120+(70*(i-1))
         WIDTH 200+i%,200
         HEIGHT 200+i%,55
         CAPTION 200+i%,NM$(i%)
    NEXT i%

   ...
   ....

En faisant cela, si tu définis des plages de numérotation pour tes objets comme le propose Klaus, tu vas alléger ton programme.
De plus dans l'exemple que j'ai mis, tu as un numéro de base à 200. Dans le code, ce numéro est figé en dur.
Si demain tu dois déplacer un tout petit peu la numerotation (car tu veux insérer d'autres objets avant 200), tu es obligé d'aller modifier de partout dans le code ce numero de base (200).

La meilleure solution  à mes yeux c'est de définir au début du programme des pseudo-constantes.
Par exemple :

Code:

DIM BASE_CDE_MANU: BASE_CDE_MANU = 200
...
... puis plus loin dans le code
....
Mask_Commandes_Depart_Manuel:
      ALPHA BASE_CDE_MANU
         FONT_SIZE BASE_CDE_MANU, 18
         LEFT BASE_CDE_MANU, 400
         TOP BASE_CDE_MANU, 30
         CAPTION BASE_CDE_MANU, "Commandes départ manuel"
  
  ' ------------- 1ère colonne --------------------
    FOR i% = 1 TO 6
      BUTTON BASE_CDE_MANU+i%
         LEFT BASE_CDE_MANU+i%,205
         TOP BASE_CDE_MANU+i%,120+(70*(i-1))
         WIDTH BASE_CDE_MANU+i%,200
         HEIGHT BASE_CDE_MANU+i%,55
         CAPTION BASE_CDE_MANU+i%,NM$(i%)
    NEXT i%

Demain si tu dois décaler la numérotation, tu n'as juste qu'une ligne à modifier : là où se trouve ta constante (par ex. BASE_CDE_MANU).
Perso, pour définir des constantes et pour les reconnaitre, je les déclare en majuscules...

Bonjour Nardo26,

Oui, tu as raison, le programme n’est pas du tout optimisé. Il est en cours de développement et, est loin d’être fini.

Tout au contraire, je l’ai « étiré » (décomposé en éléments simples) pour améliorer la lisibilité, et faciliter les modifications.

L’optimisation du code ne se fera qu’à la fin, en espérant y arriver.

Très bonne journée !

Je te conseille de penser à ce genre d'optimisation dès le départ.
- Pour le debuggage, c'est plus simple de parcourir 2000 lignes de code que 6000...
- Une fois que ton prog sera "terminé", tu ne pourras/voudras plus y toucher.
- tu gagnes en lisibilité/maintenance : dans 6 mois, tu ne te souviendras plus à quoi correspond par exemple l'objet 20.

Après, c'est vrai tu fais comme tu veux..

Tout à fait d' accord avec vous Klaus et Nardo mais je comprends aussi
Marc.
Moi même, à mes débuts, je déclarais tout en dur et tout était détailler puis
avec la maitrise du langage qui avance on finit par ce servir des boucles et des
tableaux.
Il m' a bien fallu un mois pour assimiler les procédures...