Pourquoi PARENT 2,0 ne marche pas ?

Par la commande PARENT, je place un OPTION_CONTAINER dans un CONTAINER. Cela marche bien.

Puis, je veux sortir mon OPTION_CONTAINER pour le remettre sur la FORM 0, et ça ne marche pas !
Message: "Impossible to link".

Voici un exemple:

Code:

container 1 : top 1,100 : left 1,10 : width 1,300 : height 1,300
container_option 2 : top 2,20 : left 2,10
message "Placer le container_option dans le container"
parent 2,1
message "Placer le container_option sur la form 0"
parent 2,0

end

Or, la doc ne cite pas ce cas comme étant un cas exclu (à moins que j'aie la berlue). Comment puis-je annuler une commande PARENT par programme ?

Bonjour Klaus,

En effet, la commande PARENT est à usage unique: une fois qu'un parent est défini on ne peut plus le changer...(et pas seulement avec 0)
voir ici

Bonjour Klaus
Toutes commandes parent n,0 te provoquera la même erreur impossible to link! La seule solution, c'est de supprimer ton objet et de le recréer tout simplement sans commande parent.
A+

@Nardo26:
Si, si, on peut donner un autre parent à n'importe quel objet qui est déjà apparenté à un premier objet. J'ai étendu mon exemple pour passer le option_container 2 d'abord dans le container 1, puis dans le container 3, puis j'essaie de le mettre sur la form 0.

Je trouve que ce comportement n'est pas logique, pour parent N,0. Cela devrait marcher. 0 est une form qui est une cible autorisée pour la commande PARENT.

@Bidnono:
C'est bien ce que je craignais. Supprimer et recréer l'objet est effectivement une solution mais cela pose vite problème si l'objet est un mémo ou un grid, cas les données sont perdues et il faut les sauvegarder et restaurer. Quelle gymnastique pour une fonction absolument élémentaire ! Et que dire s'il s'agit d'un objet qui est lui-même parent d'autres objets ? Comme un container, un option_container ou un sous-menu ? Cela veut dire qu'on ne peut pas déplacer une branche de menu une fois qu'elle est créée !

Jack pourrait peut-être jeter un coup d'oeil pour savoir s'il est possible de permettre PARENT N,0 pour remettre un objet sur la form 0 ? Tout comme on peut le placer dans une autre form si le deuxième paramètre est le numéro d'une form ? Alors pourquoi pas la form 0 ?

Voici une démo:

Code:

width 0,700
container 1 : top 1,100 : left 1,10 : width 1,300 : height 1,300
container_option 2 : top 2,20 : left 2,10
container 3 : top 3,100 : left 3,320 : width 3,300 : height 3,300
form 4 : top 4,400 : left 4,500
message "Placer le container_option dans le container 1"
parent 2,1
message "Placer le container_option dans le container 3"
parent 2,3
message "Placer le container_option dans la form 4"
parent 2,4
message "Placer le container_option sur la form 0"
parent 2,0

end

EDIT

Dans le même esprit, j'ai déjà posé la question: pourquoi on ne peut pas mettre un SCENE3D dans un container par la commande PARENT ? C'est bien le seul objet visuel pour lequel cela n'est pas possible !

Ok Klaus,
mais il me semblait que cela ne marchait pas avant...

concernant PARENT, tu as raison, le FORM 0 ne devrait pas être différent des autres...

Bonsoir,
Ces dernier temps, j'ai vu que Klaus disait que menu ne fonctionnait qu'avec la form 0.
Cela me semblait curieux car j'étais certain que cela marchait avant. Il me semblait avoir posté un problème sur le report d'un menu d'une forme à une autre, mais là je n'ai recherché.

Par contre j'ai retrouvé ceci, qui montre que le menu pouvait être aussi sur une autre forme que 0. Dans cet exemple, c'était form 38.
https://panoramic.1fr1.net/t911-hide-sur-form-avec-menu
Donc je pense qu'on peut parler de bug.

@Cosmos70:
J'ai effectivement dit récemment qu'un menu ne fonctionne qu'avec la form 0. C'était une ânerie, et j'avais rectifié rapidement par un post suivant. Donc, s'il vous plaît, ne tenez pas compte de ce message erroné comme quoi le menu ne fonctionnerait qu'avec la form 0 !

Ceci dit, cela n'enlève rien à la pertinence de ce que je relève pour la commande parent avec la cible étant la form 0. Cela devrait marcher !

Désolé Klaus, j'ai pas fait gaffe.

Mais à l'époque il me semblait avoir posé des questions, concernant le déplacement du menu d'une form à l'autre.
Je sais de mémoire que j'avais procédé de la sorte pour que ça marche: j'ai mis le menu dans un sous-programme, et pour passer sur l'autre form, je détruisais le menu, et par le s/prg je le recréais sur l'autre form.

Là je suis moins sûre, mais il me semblais que Jack avait procédé à la rectification pour le report du menu. Je sais aussi qu'il fallait alors effacer chaque sous-menu et ensuite le parent pour effacer le menu, et là Jack avait rectifié.

J'ai vraiment pas le temps d'aller farfouiller dans les fin-fond du forum pour retrouver.
Quoiqu'il en soit, comme tu pourrais le dire; "ça me fais une belle jambe maintenant de savoir cela, vu que ça ne résout pas le problème aujourd'hui."

Désolé de t'avoir embarrassé sur cette question.

Cela ne m'embarasse pas du tout. Cela prouve surtout qu'il s'agit d'un problème ancien qui n'a jamais été résolu.

Pour apporter une précision par rapport aux menus (mais cela vaut également pour les container et option-container:
- on peut déplacer un tel objet d'un parent à un autre, tant que le parent cible n'est PAS la form 0
- on peut supprimer un tel objet, et tout son contenu sera supprimé automatiquement (c'était la correction ou l'extension fonctionnelle que Jack avait apporté à l'époque)
- on ne peut PAS attacher un objet quelconque à la form 0 par la commande parent

Et c'est bien ce dernier point qui pose problème. Imaginez un container_option avec un certain nombre d'options, dont certaines sont cochées. Ce container_option est placé dans un container 1. Maintenant, pour des raisons quelconques, je veux déplacer ce container_option dans le container 2. Pas de problème - ça marche. Si je veux le déplacer dans une autre form, sans même qu'il soit dans un container - ça marche. Mais si je veux le déplacer sur la form 0 - BOUUUUUUUUUUUUM............

Ce n'est pas normal. Jack, s'il te plaît, pourrais-tu nous donner un petit "bonbon" pour permettre que la form 0 soit la cible de la commande parent, quelque soit l'objet ?

Voici les règles actuelles qui régissent la commande PARENT.

Impossibilité d'un parent:
FORM, DLIST : PARENT est refusé.
SCENE3D, MAIN_MENU, OPEN_DIALOG, SAVE_DIALOG : PARENT est refusé. Il faut faire COMMAND_TARGET_IS au préalable.

Possibilité d'un parent:
SOUND : le PARENT doit être un FORM créé.
SUB_MENU : le PARENT doit être un MAIN_MENU ou un SUB_MENU.
OPTION : le PARENT doit être un FORM créé, un CONTAINER ou un CONTAINER_OPTION.
BUTTON, EDIT, MEMO, COMBO, ALPHA, LIST, PICTURE, CHECK, OPTION, MOVIE, TRACK_BAR, SCROLL_BAR, PROGRESS_BAR, SPIN, GRID, CONTAINER, SCENE2D, CONTAINER_OPTION : le PARENT doit être un FORM créé ou un CONTAINER.

Il est possible de lever l'interdiction pour un SCENE3D et de lui affecter un PARENT.

Par contre, je n'ai jamais envisagé, donc codé la possibilité d'effectuer

Code:

PARENT N,0

car tout nouvel objet créé va automatiquement dans FORM0, à moins qu'on ait au préalable exécuté une commande COMMAND_TARGET_IS.
Ma logique était que la création de l'interface utilisateur, c'est à dire la création des objets contenants comme FORM, CONTAINER ou CONTAINER_OPTION, avec leurs objets contenus, était définitive, et que les commandes PARENT et COMMAND_TARGET_IS n'allaient servir qu'au lancement pour la création du "décor". Je ne supposais pas qu'on ferait "voyager" des objets d'un contenant à un autre pendant l'exécution.

Mais pourquoi pas ?
Si certains y voient une utilité, je vais appliquer la commande PARENT sur FORM0 pour la prochaine version, et appliquer la commande PARENT pour un SCENE3D.

C'est vrai que ce n'est pas un usage courant, mais en effet, cela peut être pratique de reprendre un objet avant de supprimer une fenêtre (le cas de l'EDI de Klaus en est une parfaite illustration, mais Cosmos en avait déjà éprouvé le besoin)

PS: Il y avait une autre question de Klaus dans ce post:

Citation :

Dans le même esprit, j'ai déjà posé la question: pourquoi on ne peut pas mettre un SCENE3D dans un container par la commande PARENT ? C'est bien le seul objet visuel pour lequel cela n'est pas possible !

Ben, relis bien la dernière ligne:

Citation :

Si certains y voient une utilité, je vais appliquer la commande PARENT sur FORM0 pour la prochaine version, et appliquer la commande PARENT pour un SCENE3D.

D'autre part, cette demande, de "faire voyager des objets d'un contenant à un autre pendant l'exécution" me réjouit et je vais la satisfaire bien volontiers.
Car, en prenant du recul, je me dis que si on en est arrivé à des demandes comme celles-ci, c'est à dire à des demandes de confort, c'est que l'essentiel de PANORAMIC a été fait.

Je suis conscient qu'il manque encore énormément (impression, tableau à 3 dimensions et plus, nouveaux objets, commandes EXCEL plus complètes, ...).
Mais je suis quand même content.
Et encore plus: dans un état de béatitude que je ne pensais jamais atteindre en lisant ce forum ...

Ah, un grand MERCI, Jack ! Cette nouvelle vient à point comme "cadeau de Noël", même si, comme d'habitude, je serai patient pour la réalisation effective.

Bien sûr, cela me rendra service dans la réalisation de mon projet actuel. Mais au-delà de cela, j'ai l'impression que ces deux points (pouvoir placer un SCENE3D dans un container au même titre qu'un SCENE2D, et pouvoir utiliser la commande PARENT avec la form 0 comme cible), vont dans le sens de la généralisation des commandes existantes, du moins du point de vue de l'utilisateur, en levant des limitations spécifiques.

En tout cas, je suis très content de ta réponse et je t'en suis reconnaissant.

Mais bon Jack pour profiter de ton état euphorique, si tu veux nous ajouter quelques petites commandes pour la 2D ou la 3D de ton cru, elles seront les bien venues et désolé de ne pas avoir vu la référence à la 2ème demande de Klaus, c'est ça de lire rapidos le forum entre 2 consultations de docs et 5 consultations de fichiers Excel qui font mal à la tête, désolé ...)

bonne nouvelle, car j'avais pris l'habitude de créer systématiquement des FORM(s) et de ne plus utiliser FORM 0, car je travaille beaucoup avec des CONTAINER(s).

Je suis content que Jack retrouve du plaisir avec de Panoramic. C'est très vrai, pour ce qui me concerne, que Panoramic est à un stade très satisfaisant. Et l'apport des SUB(s) est une grande avancée. La programmation devient plus aisée et plus claire.

Je pense que la fidélité des Panoramiciens est payante pour tous (y compris Jack).

A+