Je suis en train d'explorer les possibilités de la commande PARENT.
Pour des cas simples, pas de problème: on objet visuel (bouton, mémo, ...) peut être affecté à une form autre que form 0, ou à un container.
Un objet option peut en plus être affecté à un option_container.
Là où les choses se corsent, s'est avec les objets non visuels. A priori, aucun ne supporte la commande parent, ce qui signifie qu'ils sont tous attachés à la form 0.
Oui mais ce n'est pas le cas avec l'objet image. Il peut être affecté à un container par la commande parent. A qui il appartient, alors ? Cela semble évident, mais cela ne l'est pas. Prenons par exemple l'objet timer. Il est non visuel et ne peut pas être affecté par la commande parent, ni à un container, ni à une autre form. Pourtant, on peut utiliser la commande command_target_is. Si je crée une seconde form et je fais command_target_is vers cette seconde form, alors la commande timer crée un objet sans rechigner, mais il reste attaché à la form 0 sans prévenir !
Et j'en ai une preuve: avec ma commande inactive sur une form ou un container, on peut rendre inactifs; d'un seul coup, tous les objets de cette form ou de ce container. Ce comportement est excellent. Mais notre timer affecté à la seconde form par command_target_is resta actif si je désactive cette form par la commande inactive.
Et c'est là qu'il y a une incohérence. La commande parent est bien rejeté par le compilateur sur tous les objets non visuels (timer, open_dialog, dlist, ...) SAUF sur l'objet image d'ailleurs, mais la commande command_target_is ne conduit pas à un message d'erreur si l'on tente de créer un de ces objets non visuels, et on a l'impression que tout est affecté à la cible de command_target_is alors que ce n'est pas vrai.
J'ai quelques suggestions à faire:
1. améliorer la documentation de command_target_is: elle dit simplement que toutes les commandes ultérieures s'appliquent à la form ciblée par command_target_is. Or, ceci n'est pas vrai pour les commandes créant des objets non visuels
2. bloquer la commande parent sur l'objet image, dans un souci de cohérence avec les autres objets non visuels
3. à l'image de container_option, créer un nouvel objet container_timer qui ne peut recevoir que des objets timer.
4. créer les comandes suspend/restart permettant de suspendre les évènements d'un objets, sans annuler la déclaration de la routine d'évènement. Et la commande suspend sur un container_timer suspend la reconnaissance de tous les évènements on_timer pour les objets de cette collection, et la commande restart sur un container_timer réactive tous les on_timer. Elle désactiverait en fait tous les évènements (on_timer, on_click, on_change, ...) de tous les objets d'une collection (form, container, container_option, container_timer). Et ceci a un gros avantage: d'une seule commande, on peut bloquer ou relancer plusieurs timer, et on peut dès lors les gérer facilement par groupes. De plus, on n'aurait plus à respécifier chaque fois la routine d'évènement comme dans la situation actuelle où il faut faire off_timer ou off_click pour désactiver, puis on_timer ou on_click pour réactiver, mais il faut redonner le nom de la routine. Et ceci est gênant car on ne peut pas mettre le nom de la routine dans un string ou dans une variable - il est codé en dur dans le source. Si l'on doit toucher les routines de plusieurs objets simultanément, cela représente une lourdeur de programmation et une source d'erreurs.
Donc, résumé:
- clarification de la doc sur command_target_is
- blocage de la commande parent sur l'objet image
- création de l'objet container_timer
- création des commandes suspend/restart
Accueil 
Calendrier
