Crash récurent de l'éditeur

Pourquoi tant de haine en permanence ?

Je up le sujet... Suis-je seul à vivre cette infamie par trop récurrente ?

Non, non... tu n'es pas le seul. C'est récurrent, et j'ai cela également, de temps en temps.

J'en prends mon partie et enregistre souvent.

J'ai aussi ce problème, je crois qu'on l'a tous.
Ma solution est la même que Klaus, prendre le réflexe de sauver souvent.

Une question Fredisland:
Maintenant que ton éditeur fonctionne, as-tu essayer de programmer avec pour voir s'il n'y pas le même problème.

A+

C'est surement lié à l'OS, sous XP c'est extrèmement rare que ça arrive, sous windows 10, je n'ai pas testé assez longtemps, mais pour l'instant, pas de pb.
Essaye l'éxécution en mode compatibilité pour des OS plus ancien et dis nous si c'est mieux...

Pour ma part, que ce soit XP, Seven ou W10, j'ai les mêmes désagréments.

Je suis sous W10, et ça arrive une fois par semaine ou une fois en 10 jours, en gros. Ce n'est donc pas fréquent du tout, surtout en utilisation intensive. Et encore, en permanence avec des DLLs en mise au point que qui peut générer des conflits. Je ne m'alarme donc pas de ces rares plantages et je relance.

Je suis sous Windows 7.32 bits.

Pour moi, ça arrive 9 fois sur dix.
C'est très fréquent et c'est pour cela que j'avais pas mal commenté ce problème qui est très désagréable.
Pour moi, c'est un des points les plus urgent que Jack doit régler.
S'il le peut... car à priori le problème ne semble pas si simple à résoudre...

D'ailleurs puisqu'on en parle, j'ai remarqué que si je lance le programme une première fois,
si je vois qu'il ne se lance pas aussi rapidement que d'habitude,
sans attendre plus, je relance une seconde fois son exécution
et là comme par miracle le lancement du programme se fait correctement.

C'est très étrange comme bug car il y a plusieurs cas de figure possible.

Certains avaient émis l’hypothèse qu'un soucis dans la sauvegarde. Je pense que c'est une piste intéressante.
Je me demande s'il n'y a pas aussi les emplacements des fichiers et de l'éditeur qui jouent aussi...

Espérons que Jack puisse trouver le problème...

Petit complément d'information:
j'utilise la toute dernière version de Panoramic_Editor. Je suis conscient que cela peut conduire à mettre en lumière certaines "maladies d'enfance". Mais, très sincèrement, je trouve cette dernière version remarquablement stable, comparée aux versions précédentes. Rendons à César ce qui est à César: de gros progrès ont été faits. C'est du moins mon expérience personnelle.

Jean Claude a écrit:

Une question Fredisland:
Maintenant que ton éditeur fonctionne, as-tu essayer de programmer avec pour voir s'il n'y pas le même problème.A+

Oh que oui !!!! Et franchement, mon taux dé démotivation augmente d'un cran à chaque fois... Et ce ne sont pas les "explications "imbuvables qui me rassurent :

Signature du problème :
 Nom d’événement de problème: APPCRASH
 Nom de l’application: PANORAMIC_TEMP_+Editeur.exe
 Version de l’application: 1.0.0.0
 Horodatage de l’application: 2a425e19
 Nom du module par défaut: KERNELBASE.dll
 Version du module par défaut: 6.1.7601.23915
 Horodateur du module par défaut: 59b94abb
 Code de l’exception: 0eedfade
 Décalage de l’exception: 0000c54f
 Version du système: 6.1.7601.2.1.0.256.48
 Identificateur de paramètres régionaux: 1036
 Information supplémentaire n° 1: bc07
 Information supplémentaire n° 2: bc07567ad441d1cbb41e1bfbcfa3d9bf
 Information supplémentaire n° 3: 442f
 Information supplémentaire n° 4: 442f53aef3dc8c92ab3e8fa7ec7eab79

Bonsoir.
J'ai hésité d'intervenir, car ce que je pense avoir remarqué, je n'en suis pas certain, mais si cela pouvait-être l'une des pistes à explorer, il vaut mieux que j'en parle.

Déjà au départ j'ai l'impression qu'il y a deux sortes de plantage: celui de Panoramic qui détecte une erreur, et une de Windows. Il est parfois difficile de savoir qui intervient.

Mais à force j'ai l'impression que cela vient des événements. A force de relancer Panoramic et de faire les mêmes interventions, je me suis posé la question, au vu des réponses, si il n'y avait pas conflit entre ceux-ci.

Ainsi j'ai revu un peu les appels, et j'ai tout bloqué, et laissé juste un ou deux en fonctionnement. Depuis j'ai plus (+) de stabilité. Je ne peux tout contrôler à la fois, mais par exemple j'ai souvent le même rapport d'erreur qui est qu'une variable local est déjà déclarée. Mais voila, je constate qu'à un moment j'ai un ON_CLICK sur un label, et un ON_KEY_DOWN pour un autre label.

N'y aurait pas un conflit avec le fait de cliquer à un moment et sur lequel j'ai une pause pour le relachement, et on_key_down.

Je mets entre parenthèses car je me pose une question pendant que j'écris, et je vais essayer de vérifier une chose. Je publie quand-même des fois que ce serait une piste.

remarque: Avant on_key_down je ne m'en servais pas.

Les évènements ne sont pas forcément déclenchées au même moment.
ON_MOUSE_DOWN est déclenché lorsqu'on enfonce le bouton.
ON_CLICK est déclenché lorsqu'on relâche le bouton, idem pour ON_MOUSE_UP.
Démonstration:

Code:

label mousedown, click

' edit 1 : text 1,"Cliquer ici..."
panel 1 : caption 1,"Cliquer ici..."
on_mouse_down 1,mousedown
on_click 1,click

end

mousedown:
  caption 0,"MOUSE DOWN"
  return
 
click:
  caption 0,"CLICK"
  return
 

Activer le PANEL ou le EDIT, puis cliquer lentement sur l'objet, en observant la barre de titre.
Ensuite, cliquer rapidement plusieurs fois, et on constate que, dans certains cas, l'évènement ON_CLICK est "mangé", car il est bloqué par un nouveau MOUSE_DOWN.

Pour ma part, j'évite d'utiliser ces deux évènements simultanément sur le même objet. Mais de façon générale, il est certain que des évènements "en rafale" ont tendance à se télescopier, car les temps d'exécution en Panoramic d'une routine évènement sont beaucoup plus longs que ce qui serait requis pour pouvoir gérer des évènements se succédant rapidement.

Seule solution: coder les évènements avec parcimonie, et surtout ne pas hésiter à désactiver tel ou tel évènement par les commandes OFF_xxx à l'entrée d'une routine évènement et réactiver par ON_xxx à la fin. Et ceci ne concerne pas uniquement l'évènement qu'on vient de recevoir, mais également tous ceux dont le traitement pourrait perturber la routine évènement en cours d'exécution. Ceci est particulièrement vrai pour les TIMER.

Et puisqu'on en est à essayer de trouver des solutions, je viens ici éclairer sur l'utilisation de ON_MOUSE_MOVE.

ON_MOUSE_MOVE, comme son nom l'indique, est un événement qui se déclenche à chaque MOUVEMENT de la souris sur un objet. Ce qui signifie qu'il est vain (et dangereux) de l'utiliser en remplacement des (non encore implémentés) ON_MOUSE_OVER et ON_MOUSE_OUT très connus des codeurs en javascript ou encore OnMouseEnter et OnMouseLeave de Lazarus. Utiliser ON_MOUSE_MOVE pour changer l'image au survol d'une picture ou d'un bouton, c'est demander de charger en une fraction de seconde 100 fois la même image sur le même objet si la souris s'est déplacée de 100 pixels sur l'objet concerné. On imagine aisément le goulet d'étranglement et... le plantage potentiel (et généralement effectif).

À à ce jour, il n'existe donc pas à ma connaissance de solution "propre" pour simuler le survol d'un objet en BASIC PANORAMIC, ce qui est extrêmement regrettable car la gestion de ce type d'événement n'a rien d'exotique dès lors qu'l s'agit de réaliser des interfaces graphiques.

Le code ci-dessous permet de mettre en évidence le fonctionnement de ON_MOUSE_MOVE :

Code:

' Centrage de la form 0
width 0,640 : height 0,480
left 0,(screen_x/2)- width(0)/2  : top 0,(screen_y/2) - height(0)/2
picture 1 : width 1,200 : height 1,200 : top 1,140 : left 1,220 : color 1,255,200,200

label move_on_form,move_on_picture

on_mouse_move 0, move_on_form
on_mouse_move 1, move_on_picture
END

move_on_form:
    print_locate 10,10
    print "FORM 0 : X=" ; mouse_x_position(0) ; " - Y=" ; mouse_y_position(0)
return

move_on_picture:
    print_locate 480,10
    print "PICTURE 1 : X=" ; mouse_x_position(1) ; " - Y=" ; mouse_y_position(1)
return

@Klaus,

Je suis d'accord avec toi. Mais

Le but est de déterminer la cause des erreurs d'un programme. Ors le problème est qu'il s'agit de programme qui fonctionne  Donc n'importe quel programme de démonstration pour montrer la validité d'un fonctionnement correct n'apporte aucune démonstration.

Par exemple sur le code que j'utilise, tout fonctionne. Et l'un des cas de blocage, et bien sans rien faire, ni avec le clavier, ni avec la souris, voila qu'au bout d'un certain temps, le programme se bloque avec une erreur signalée comme quoi une variable est déjà déclarée, et bien souvent c'est dans la zone de déclaration de départ, celle avant le END. Vraiment c'est n'importe quoi. C'est d'ailleurs là que j'ai voulu me servir de TRACE_ON et d'y mettre une sortie d'erreur avec ON_ERROR_GOTO.

ON_TRACE ne sert à rien, vu que celle-ci se ferme après un dizaine de lignes, alors que le programme continu. J'y avais ajouté dans le programme d'erreur NUMBER_EVENTS et cette instruction me signale toujours 0, au point de me demander si celle-ci sert vraiment, vu que je trace à plein d'endroit cette instruction et j'ai toujours 0.

Bon je pense que j'ai dis ce qu'il fallait, et je peux retourner dans mon monde, mais pour moi toutes les pistes sont ouvertes.

moi-même a écrit:

Et l'un des cas de blocage, et bien sans rien faire, ni avec le clavier, ni avec la souris, voila qu'au bout d'un certain temps, le programme se bloque

C'est pas tout à fait vrai. C'est le cas pour Panoramic, mais je suis le programme avec mon éditeur qui est pour ce programme EditPad. Panoramic continu t'il à prendre des événements alors que je regarde les lignes de mon programmes

@Fresidland:
Tu peux réduire sensiblement la charge système due aux traitements des ON_MOUSE_MOVE si tu fais ceci:

Code:

' Centrage de la form 0
dim ObjetActuel%
width 0,640 : height 0,480
left 0,(screen_x/2)- width(0)/2  : top 0,(screen_y/2) - height(0)/2
picture 1 : width 1,200 : height 1,200 : top 1,140 : left 1,220 : color 1,255,200,200

label move_on_form,move_on_picture

ObjetActuel% = -1
on_mouse_move 0, move_on_form
on_mouse_move 1, move_on_picture
END

move_on_form:
    if ObjetActuel%=0 then return
    ObjetActuel% = 0
    print_locate 10,10
    print "FORM 0 : X=" ; mouse_x_position(0) ; " - Y=" ; mouse_y_position(0)
return

move_on_picture:
    if ObjetActuel%=1 then return
    ObjetActuel% = 1
    print_locate 480,10
    print "PICTURE 1 : X=" ; mouse_x_position(1) ; " - Y=" ; mouse_y_position(1)
return

@fredisland
Il existe des commandes pour stopper le traitement d'un 'event' afin qu'il ne s'appelle pas lui-même:

Code:

' Centrage de la form 0
width 0,640 : height 0,480
left 0,(screen_x/2)- width(0)/2  : top 0,(screen_y/2) - height(0)/2
picture 1 : width 1,200 : height 1,200 : top 1,140 : left 1,220 : color 1,255,200,200

label move_on_form,move_on_picture

on_mouse_move 0, move_on_form
on_mouse_move 1, move_on_picture
END

move_on_form:
off_mouse_move 1 : off_mouse_move 0
    print_locate 10,10
    print "FORM 0 : X=" ; mouse_x_position(0) ; " - Y=" ; mouse_y_position(0)
on_mouse_move 0, move_on_form : on_mouse_move 1, move_on_picture
return

move_on_picture:
off_mouse_move 0 : off_mouse_move 1
    print_locate 480,10
    print "PICTURE 1 : X=" ; mouse_x_position(1) ; " - Y=" ; mouse_y_position(1)
on_mouse_move 1, move_on_picture : on_mouse_move 0, move_on_form
return

@oscaribout
'number_event' est bogué, regarde la réponse de jack ici

Merci Silverman. Je l'ignorai

Pas de trace, pas de number_events, difficile d'explorer les problèmes de Panoramic. Jack est débordé, je ne peux rien lui demander. Un jour viendra

silverman a écrit:

@fredisland
Il existe des commandes pour stopper le traitement d'un 'event' afin qu'il ne s'appelle pas lui-même...

Merci beaucoup pour l'astuce, je vais m'en inspirer fortement pour alléger l'affaire