Modification de CONTAINER

J'utilise souvent l'objet CONTAINER pour activer/Désactiver un groupe d'objets avec une seule commande. Mais quelques fois, le cadre (et le libellé) gênent. Je peux ne pas mettre de libellé, mais le cadre s'affiche toujours. J'aurais deux suggestions à faire:

1. deux nouvelles commandes
BORDER_ON N et BORDER_OFF N pour gérer l'affichage ou non du cadre du container
ou
BORDER_HIDE N et BORDER_NORMAL N agit aussi sur le container, avec le même effet.

2. un nouvel objet
COLLECTION N
avec une commande
MEMBER N,M
L'objet collection agirait exactement comme un CONTAINER, mais n'a aucune représentation visuelle. On pourrait lui appliquer HIDE, SHOW, ACTIVE, INACTIVE, mais pas TOP, LEFT, WIDTH, HEIGHT, COLOR, FONT_xxx etc, n'ayant pas de représentation visuelle. La commande MEMBER agirait exactement comme une commande PARENT, mais n'agirait pas sur la propriété "parent" qui resterait inchangée pour les objets concernés. C'est un simple regroupement d'objets qui devient référençable par le numéro de la collection.

Personnellement, j'ai une préférence pour la seconde solution. Elle permettrait d'aller beaucoup plus loin: regrouper fonctionnellement par exemple des objets n'étant pas localisés physiquement dans la même section de la form. On pourrait regrouper des boutons d'une barre d'outils avec des mémos, edits etc, des objets sur d'autres forms également, même des forms entières. Cela permettrait de gérer complètement l'aspect visuel de l'interface graphique, en fonction de la situation du programme, avec des commandes très simples et intuitives. Il suffirait de préparer ses collections pour ensuite chosir, à tout moment, celle ou celles qui seront à montrer ou à cacher.

Je préfère aussi la 2ème solution,

pour la première et pour éviter des confusions avec FORM:
CONTAINER_BORDER_ON N et CONTAINER_BORDER_OFF N pour gérer l'affichage ou non du cadre du container
ou
CONTAINER_BORDER_HIDE N et CONTAINER_BORDER_NORMAL N agit aussi sur le container, avec le même effet.

qu'en penses-tu ?

A+

Ce serait logique, Jean-Claude. Je voulais juste éviter de créer un nouveau mot-clé. Mais de toutes façons, ma préférence va à la seconde solution, qui offre une souplesse bien plus grande.

Lu et approuvé !

Bonjour,
La deuxième idée est pas mal. J'ai déjà pensé à ce genre chose, sans penser à le demander, et aussi sans savoir ce qu'il faudrait faire. Vu comme tu le vois, c'est très bien.

Klaus a écrit:

2. un nouvel objet
COLLECTION N
avec une commande
MEMBER N,M
L'objet collection agirait exactement comme un CONTAINER, mais n'a aucune représentation visuelle. On pourrait lui appliquer HIDE, SHOW, ACTIVE, INACTIVE, mais pas TOP, LEFT, WIDTH, HEIGHT, COLOR, FONT_xxx etc, n'ayant pas de représentation visuelle. La commande MEMBER agirait exactement comme une commande PARENT, mais n'agirait pas sur la propriété "parent" qui resterait inchangée pour les objets concernés. C'est un simple regroupement d'objets qui devient référençable par le numéro de la collection.

Dans le cadre de l'objet COLLECTION: pourquoi rajouter une commande MEMBER ?
PARENT suffit pour lier les objets.
Sachant que "COLLECTION" possède lui aussi un PARENT, il ne me parait pas nécessaire de rajouter la commande MEMBER.

Code:

FORM 100
COLLECTION 1:PARENT 1,100
BUTTON 2:PARENT 2,1

Dans l'exemple ci-dessus, le BUTTON 2 est le fils de COLLECTION et le petit-fils de FORM 100...

Oh non. Dans mon idée, PARENT n'est pas du tout identique à MEMBER. Pour moi, une collection, elle-mpeme invisible au demeurant, doit pouvoir regrouper des objets répartis sur des FORMS, des CONAINER et des OPTION_CONTAINER variés. Si on utilisait la commande PARENT pour cela, ces objets disparaîtraient de leur cadre/contenant/localisation pour apparaître - où ? dans un objet invisible ?

Non, dans mon esprit, COLLECTION est exactement ce que le mot indique: un regroupement logique mais non visible en lui-même, d'objets très divers, pouvant même inclure des objets SUB_MENU. Ceci permet d'agir très simplement sur des objets répartis au 4 coins de l'application, pour les ctiver ou désactiver parf exemple, y compris les lignes de sous-menus. Tout l'intérêt de l'objet COLLECTION est là. Car sinon, on a CONTAINER qui à l'aide de la commande PARENT regroupe très bien des objets, mais uniquement à l'intérieur de son espace graphique. Et impossible de mettre un SUB_MENU dans un container.

J'avais pas bien compris ton histoire de MEMBER....
Vu comme ça je suis d'accord : cela permettrai par exemple de cacher / montrer des fonctionnalités situées à plusieurs endroits dans un prog suivant les boites à cocher d'une option ou de la présence ou non d'une DLL....

C'est ça. Pour le moment, je constitue des tables ou des dlist contenant chacune une série de numéros d'objet, et je passe dessus avec une boucle pour effectuer les actions dont j'ai besoins. Mais c'est lourd et pas facile à maintenir, en cas de modification de la configuration de l'application.

Pour implémenter un tel objet COLLECTION, cela pourrait être fait par un objet TLIST ou TObjectBucketList. Dans ce dernier cas, on peut agir facilement sur l'ensemble des membres par un FOR EACH ... ce qui correspond à l'esprit de ce que je voudrais faire avec une collection.

Je vais patauger 5 mn pour m'en servir
mais je te suis sur cette demande

Klaus a écrit:

C'est ça. Pour le moment, je constitue des tables ou des dlist contenant chacune une série de numéros d'objet, et je passe dessus avec une boucle pour effectuer les actions dont j'ai besoins. Mais c'est lourd et pas facile à maintenir, en cas de modification de la configuration de l'application.

Pour implémenter un tel objet COLLECTION, cela pourrait être fait par un objet TLIST ou TObjectBucketList. Dans ce dernier cas, on peut agir facilement sur l'ensemble des membres par un FOR EACH ... ce qui correspond à l'esprit de ce que je voudrais faire avec une collection.

Ca me fait penser : il en est où Jack avec la version de Panoramic avec passage de paramètres (fonction) ?
L'utilisation des Dlist, dans ce cas, serait facile à mettre en place...
Cela pourrait justement alléger la liste des commandes en natif de Panoramic... et donc on solliciterai moins Jack pour créer des nouvelles commandes comme ces fameuses COLLECTION et MEMBER... Jack aurait tout à y gagner dans l'histoire .
Je suppose qu'il a du bloquer à un moment donné par rapport au parser ou autre élement de l'interpreteur (?)...
Peut être qu'avec la nouvelle piste de developpement (FBasic) cela sera plus simple (?)