Suppression d'un objet système: DELETE

Je crée un objet système temporaire (FORM) que je désire supprimer après usage.
Malheureusement, cet objet contient un autre objet, par exemple BUTTON, qui est la cible d'un ON_CLICK, aussi à la suppression du FORM je pars en erreur:
Access violation at address 00403DE4 in module 'PANORAMIC.exe'...
exemple:

Code:

Label Forme, Suppr
button 1: Caption 1, "Créer"
on_click 1, Forme
end

Forme:
Form 100: Top 100,100
Button 101: Left 101,100: Parent 101,100: Caption 101,"Supprimer": On_Click 101,Suppr
Return

Suppr:
Delete 100
Return

La documentation DELETE précise bien: "Si l'objet système est une CIBLE pour le dessin en 2D, pour l'impression ou pour les commandes, il est INTERDIT de le supprimer: il faut changer l'objet système ciblé avant sa suppression, avec la commande 2D_TARGET_IS".
Comment faire pour le cas du On_Click ? Il faudrait un genre de On_Click Nul, quelque chose comme ça...
Dans l'exemple ci-dessus, si je fais Command_Target_Is 0 avant la suppression, ça ne change rien.
Je précise que l'erreur 'Access violation...' est plutôt un warning, qui n'empêche pas de continuer, et qui bizarrement n'est signalée qu'une fois.

Bonjour,
Un premier teste je n'avais pas d'erreur, mais passant par mon lodear de PSPAD, j'utilise la fonction chain par lancer le programme.
Avec la fonction chain d'un programme en fichier, le phénomène ne se produit pas.
J'ai refait l'essai avec l'éditeur de Panoramic, et là le comportement est identique à ce que tu dis.

Bonsoir cosmos,
Au vu de la documentation, le comportement semble normal, mais je regrette qu'on ne puisse pas désactiver le On_Click (comme on désactive le 2D_Target) d'un objet 'enfant' pour pouvoir DELETEr l'objet parent.

Oui c'est vrai. Ce que je fais personnellement est de reporter le click sur un autre élément. Tu créés un memo ou autre inutile que tu cache, et tu le reportes dessus.

Oui en effet,

Dans le même style que TIMER_OFF,
cela serait intéressant d'avoir une commande OFF_CLICK N.

J'ai remarqué également que la commande PARENT est à usage unique:
Une fois qu'on a définit un objet avec la commande PARENT, on ne peut plus redefinir le parent de cet objet.
ex:

Code:

FORM 1
BUTTON 2:PARENT 2,1
WAIT 1000
PARENT 2,0

On obtient avec l'exemple ci-dessus le message : "Impossible to link. Line 4"

Bizarre je l'ai déjà fait avant, et ça fonctionnait ???.
Je pars, 200km Salut

Cosmos, je ne comprends pas ce que tu entends par reporter le clic sur un autre élément, ça ne résout pas le problème !
Par exemple dans mon exemple ci-dessus, si juste avant le delete 100 je fais on_click 101,Forme l'erreur est toujours là.
Ce qu'il faudrait comme dit Nardo c'est un Off_click pour désamorcer le on_click.

@Nardo tu as raison pour la parenté, mais ça me paraît un peu acrobatique de redéfinir le parent d'un objet ? enfin jusqu'ici ça ne m'a pas manqué... mais qui sait ?

@JL35: Si tu t'inspire du programme de Severin (DLL form):

Tu mets en place 2 FORM et un objet TEXT.

Puis tu veux faire des tests pour connaitre quel est le formulaire actif
et que tu veux faire balader ton objet TEXT d'un formulaire à un autre pour afficher du débug, un "coucou c'est moi" ou autre chose (bon c'est vrai que c'est un peu tiré par les cheveux)

Dans ce cas là, tu as envie de déclarer un seul objet TEXT... (pourquoi en utiliser 2 qui doivent contenir la même chose?) et utiliser la commande PARENT pour réaliser la chose.

Je pense que la commande PARENT a surtout était prévu pour définir un MENU.
Dans les autres cas, un simple COMMAND_TARGET_IS suffirait...


Mais c'est vrai, qu'il ne doit pas y avoir beaucoup d'application qui ont besoin de ce faire cette manip...

Pour revenir au problème du DELETE, j'ai pensé à PARENT (dans le cas d'un partage d'objet entre plusieurs FORM)

J'étais trop occupé pour faire des essais avec vos programme.
Cela est chose faite, et effectivement rien ne fonctionne bien.
On ne peut remettre le parent du bouton sur la forme 0, je sais que cela fonctionne avec menu.
Supprimer le bouton ne pose pas de problème. (mis un wait 1000 en delete 101 et delete 100)
Mettre on_click 101, une sub routine bidon n'a pas de sens, vu que delete 101 pose pas de problème, mais comme 101 fait parti de la forme 100, ça n'a pas de sens. Il sera détruit.

J'ai commis une mauvaise action: tout ce que j'ai dis est faux pour ce cas là. Il faut vraiment faire les essais pour répondre.

@nardo26

Citation :

cela serait intéressant d'avoir une commande OFF_CLICK N.

Ben, ça existe déjà...
Depuis la V 0.9.19 du 17 juin 2010 ...
Tout comme OFF_CHANGE, OFF_TIMER, OFF_KEY_DOWN, OFF_KEY_UP.

Par défaut, le PARENT d'un objet est FORM0. Par conséquent, pour l'objet N, faire PARENT N,0 revient à réinitialiser PARENT N,M.
Je vais regarder pourquoi la séquence suivante est interdite:
PARENT N,M
PARENT N,0

@JL35
Dans ton exemple, tu détruits le FORM 100 sur lequel est ton bouton (101) et pendant le traitement de son événement "CLIC".
Normalement, le FORM N°100 est détruit après que tous les objets qu'il contient (BUTTON N°101) soient détruits.
Mais là, on est justement en train de traiter un événement sur ce BUTTON N°101 quand cela arrive...
Je vais regarder ce cas de figure

Oups !
désolé Jack, elle m'avait échappée cette commande.
La prochaine fois, je ferai le test avant de réclamer....
J'ai parlé trop vite...

J'avais laissé ce problème de côté, mais j'ai toujours été septique sur la réponse.

Citation :

Dans ton exemple, tu détruits le FORM 100 sur lequel est ton bouton (101) et pendant le traitement de son événement "CLIC".
Normalement, le FORM N°100 est détruit après que tous les objets qu'il contient (BUTTON N°101) soient détruits.
Mais là, on est justement en train de traiter un événement sur ce BUTTON N°101 quand cela arrive...

Mais où est l’évènement?

Déjà avec la fonction CHAIN, l'erreur ne se produit pas. En plus lorsqu'on recommence à créer la form, il n'y a plus d'erreur.

Maintenant ceci:

Code:

Label Forme, Suppr
button 1: Caption 1, "Créer"
 memo  102:top 102,30
on_click 1, Forme
end

Forme:
Form 100: Top 100,100
Button 101: Left 101,100: Parent 101,100: Caption 101,"Supprimer": On_Click 101,Suppr

Return

Suppr:
repeat
  item_add 102,number_events
until number_events = 0 or scancode =0
wait 10
if number_events =0 then Delete 100
Return

L'instruction NUMBER_EVENTS nous dit qu'il n'y a plus d'évènement, à moins que je n'ai rien compris avec cette fonction.

Je reconnais que mon exemple est un peu ambigü et scabreux, détruire un bouton dans un sous programme qui est justement la cible du on_click de ce bouton...

Je ne suis pas d'accord avec toi. Il faut bien un exemple pour montrer un problème, et plus il est simple, et mieux on comprend.

Mais je crois que je suis très logique dans ma façon de penser, et je ne vois pas le problème. Il n'y a pas en mon sens de problème de structure. Tout est correct et je ne vois pas comment à notre niveau on peut éviter ce problème.

Déjà à quoi sert NUMBER_EVENTS ? J'ai déjà plusieurs fois essayé de me servir de cette instruction, et pour moi pour l'instant elle est inutile. Elle n'apporte rien.

Ensuite l'erreur que génère le programme, elle tombe sans qu'on n'y soit pour quelque chose. Ici il y a quelques lignes, mais si à l'intérieur des boucles, il y a 200 lignes, on est encore plus perdu. Cela ne vient pas de notre conception à nous, d'autant avec CHAIN, puisque chez moi, c'est l'instruction qui lance le programme et l'erreur ne se produit pas. D'ailleurs pour l'un de mes fils, je lui est fait un programme et plutôt que de mettre l'éditeur de Panoramic, vu qu'il ne programme pas, j'ai simplement fait un micro-programme utilisant CHAIN qui lit le nom du programme dans un fichier texte. Celà me permet avec 1410kb de choisir un programme BAS ou à autre à venir.

En effet, on ne peut en aucun cas supprimer un objet à partir d'une routine évènement déclenchée par cet objet ou un des objets dépendants de cet objet. L'emploi de la commande OFF_CLICK ne change rien. Le problème réside dans le fait que dès que l'objet est supprimé, l'adresse de retour de la routine d'évènement n'est tout simplement plus valide - le retour se fait dans le vide, d'où la violation d'accès.

La solution consiste en ceci:

Code:

Label Forme, Suppr
button 1: Caption 1, "Créer"
on_click 1, Forme
end

Forme:
if object_exists(100)=0
    Form 100: Top 100,100
    Button 101: Left 101,100: Parent 101,100: Caption 101,"Supprimer": On_Click 101,Suppr
else
    show 100
end_if
Return

Suppr:
rem Delete 100
hide 100
Return

Et maintenant, tout se passe bien.

Bonsoir Klaus.
Je ne remets rien en cause sur ce que tu dis. Mais je me pose des questions. Je n'ai appris que sur le tas, et ce que tu dis est abstrait pour moi.

Ton programme ok, il fonctionne, mais tu ne détruit rien, tu caches, ors l'instruction DELETE existe. Et je pose la question, à partir du moment où le END est vu, Qu'est-ce qui n'est pas évènement? Tout devient évènement, puisqu'on agit sur un clic qui nous mène à une routine. Et la routine est bien une routine évènement, il me semble.

Là où je pense comprendre ce que tu veux dire, c'est lorsqu'on veut supprimer un objet sur lequel on travail, je pense. J'ai fait un petit topo l'autre fois sur ce que je fais en ce moment, et les objets ont la possibilités de se détruire, et ça marche à merveille.

Quant à l'instruction NUMBER_EVENTS, j'aimerai bien savoir à quoi elle sert.

Il va être temps que j'aille car je me demande si je suis clair dans ce que je dis. Mais je te laisse conclure si tu veux, car je ne suis pas expert, et je te fais confiance.

D'abord, ma réponse à la partie facile de ta question:
NUMBER_EVENTS n'est cas une instruction ni une directive ni une commande, mais bien une variable système. Cette variable contient à tout moment, le nombre d'évènements en attente de traitement dans la file d'attente, et en aucun cas le nombre de routines évènement actives. Ca, à ce jour, aucun élément de Panoramic ne permet de le savoir. Alors, à quoi ça sert ? Eh bien, une routine de calcul "long" pourrait bloquer en apparence le fonctionnement du programme (aucune réaction à un clic, par exemple). alors, on peut, à intervalle régulier (en début de boucle par exemple), faire un DISPLAY si NUMBER_EVENTS est plus grand qu'un certain seuil afin de permettre l'exécution des évènements en attente. Mais que sont ces évènements comptés par cette variable ? L'ensemble des clics, erreurs, expirations de timers, changements de contenus de chams, touches frappées etc.

Maintenant, la partie technique, plus difficile:
quand tu déclares une routine par ON_CLICK, Panoramic met simplement l'adresse de cette routine en mémoire pour l'objet désigné dans la case "clic" propre à cet objet. Lorsque l'utilisateur effectue un clic, Windows signale cela à Panoramic, qui le met alors à la fin de la file d'attente des évènements réçus. Panoramic traote ces évènements dans une logique FIFO (First In, First Out) ce qui veut dire que ces évènements sont traités dans leur ordre d'arrivée. Lorsque Panoramic découvre que l'évènement à traiter est un clic de souris, il connait également l'identifiant de l'objet pour lequel le clic a été fait (c'est Windows qui le lui a signalé). Si une routine a été définie par ON_CLIC pour cet objet, Panoramic interrompt alors le cours normal de l'exécution en simulant un GOSUB à l'adresse du sousprogramme déclarée par le ON_CLIC (rappelons-nous que cette adresse a justement été mémorisée "dans" les tables décrivant l'objet. Or, pour pouvoir effectuer ce GOSUB simulé, il faut mémoriser au préalable l'adresse de retour afin de pouvoir continuer le cours normal du programme. Si maintenant, en exécutant le sousprogramme ON_CLIC, on supprime l'objet qui l'a appelé ou l'objet contenant l'objet qui l'a appelé, on perd la notion d'adresse de retour du même coup. Tant qu'un reste dans le sous-programme, tout a l'air de se dérouler bien, mais dès qu'on rencontre le commande RETURN, patatras, l'adresse de retour ne pointe plus sur une partie de code valide puisque justement, cette partie a été détruite.

Donc, dans mon petit programme, j'ai montré comment on peut obtenir visuellement le même effet SANS être obligé de supprimer l'objet, puisque cela est strictement impossible avec Panoramic.

Merci pour ta réponse.
Je ne peux pas dire grand chose, vu que je ne sais pas comment est construit Panoramic. L'histoire de pile je connais, vu que j'ai fais de l'assembleur avec 6502.

Je pense que le cas a été traité, vu que comme pour mon programme sur le poste ALPHA que je viens de répondre, je viens de faire les essais.
En compilant le programme de JL35, l'erreur subsiste
En compilant celui que j'ai mis avec number_events, c'est une autre erreur: Abstract Error

Après compilation, cela te donnes raison avec DELETE. Ce qui est étonnant c'est que si tu dis juste, je ne comprend pas pourquoi, l'erreur n'est valable qu'au premier appel. Les appels suivants le phénomène ne se produit pas. Je suppose qu'il y a une routine d'erreur qui est appelé mais qu'elle n'a pas été vu la première fois.
J’arrête, j'ai l'impression de causer dans le vide. Je ne sais pas du tout comment est fait Panoramic et mes lumières ne sont pas éclairées. Cela devient une discution inutile. Il y a ta réponse, et je la comprends. Le reste c'est du flou.

Je réédite:
Le problème pour moi, est que l'information pour savoir ce qui est possible ou non, n'est pas donné. Si on regarde la structure du programme de JL35. Est-ce que réellement il y a une erreur? Tout parait logique. C'est une erreur sur quelque chose qu'on ne voit pas, ou qu'on ne connait pas. Panoramic est été pensé pour le programmeur du dimanche".... j'envoi cela devient de l'obsession et j'aime pas tomber dans ce piège.

Pour montrer le problème avec un programme très simple:

Code:

label clic
edit 1
on_click 1,clic
end
clic:
delete 1
return

Tu vois, cela concerne TOUS les types d'objet et TOUS les types d'évènement: on ne PEUT PAS supprimer un objet dont le traitement est en cours. En aucun cas. Et tu pourras essayer de lancer ce programme par un CHAIN, l'erreur se produira quand-même.

Ca doit être une règle de conception d'un programme: ne JAMAIS supprimer un objet dont le traitement est en cours.

- Cela est aussi valable pour une form contenant un memo. Dans la routine on_change de ce mémo, tu détruis la form (ce qui détruit automatiquement le bouton) ==> crash.
- Dans une form, il y a un container qui contient un combo. Dans la routine on_click du combo, tu supprimes la form (ce qui supprime automatiquement le container ce qui à son tour détruit le combo) ==> crash
etc

@Jack: Tu pourrais peut-être faire un petit ajout dans le manuel de référence dans la rubrique DELETE ainsi que dans le Guide Utilisateur pour insérer une mise en garde appropriée.

Citation :

@Jack: Tu pourrais peut-être faire un petit ajout dans le manuel de référence dans la rubrique DELETE ainsi que dans le Guide Utilisateur pour insérer une mise en garde appropriée.

C'est noté.
Il y aura soit une mise en garde, soit un message d'erreur approprié, mais je n'ai pas encore eu le temps de regarder en détail ce qui se passe, et donc de corriger ce problème.

Je reviens sur l'instruction NUMBER_EVENTS.
Ça j'avais compris que c'était le nombre d'évènements en attente.
J'ai voulu une fois testé cette instruction lorsque je m'étais lancé dans la conception d'un éditeur Panoramic (et que j'ai du abandonné pour un problème de mémoire). J'avais un picture qui reprenait une ligne d'un edit pour mettre les mots clés en couleur, selon ce qu'ils représentaient. Je suis arrivé à plus de 8000 le nb dans events. Comment? par le on_change d'un edit. J'ai arrêté le teste, je n'en voyais pas le bout. Sans plus de précisions, on ne sait pas ce qu'on peut faire avec. C'est une info qui n'apporte rien car on n'a pas de précision.

Je viens de retrouver la question que j'avais posé à Jack. En ce temps je ne comprenais pas trop bien. Au vu de la réponse, aujourd'hui, lorsque la file est encombrée, je ne vois pas comment la vider pour exécuter une instruction urgente.
le lien: https://panoramic.1fr1.net/t557-que-peut-on-faire-avec-number_events
Tel qu'il est dit:

Citation :

Par exemple, on pourrait comparer number_events à un seuil au dessus duquel on abandonne le traitement en cours pour laisser la place aux autres:

Code:

Code:
if number_events>5 then return

D'accord pour ne pas exécuter l'instruction à venir, mais si l'exécution de ce qui est dans la file est longue, on ne peut rien y faire, ou alors il faut que cela soit déjà programmé, autrement on ne peut fonctionner en temps réel.

Citation :

NUMBER_EVENTS servira plus tard à faire des applications temps réel.

Bien j'attends la suite, vu que depuis bien 1an1/2 ou 2 ans, la question est posée. Qu'est-ce qui va permette de travailler en temps réel? (Désolé si je donne l'impression d'être négatif.)

Si j'ai un peu de temps ces jours-ci, j'essayerai un nouveau teste, en rapport à un problème que j'ai posé il y a quelque temps.

Je pense que tu vois juste: on devrait pouvoir interrompre un traitement s'il y a plus de n évènements en suspens. Par contre, ce qui est impossible, c'est de forcer le "vidage" de la file d'attente, ou forcer un évènement "prioritaire". Cela reviendrait à courcircuiter le mécanisme des messages de Windows même, et ce n'est pas possible. Ce qui est dans la file d'attente doit en sortir, ce qui veut dire que tous les traitements associés avec chaque évènement doivent se dérouler.