ToolBar / TFrame

Bonjour,

Je développe mes applications principalement à base de TFrame.
Une TFrame peut contenir une ou plusieurs TFrame qui peuvent également contenir d’autres TFrame.

Je suis à la recherche d’un composant TToolBar qui peut etre placé et visible dans un ou plusieurs TFrame en mode conception, mais dont les différents contenus seraient « mergés » et visible uniquement dans la TForm parent.

Avez vous des exemples de composants qui peuvent m’aider svp ?

Merci

Je ne crois pas que cela existe !
Tu dois pouvoir créer une Frame ancêtre TFrameWithToolBar et coder une méthode abstraite FillToolBar, celle-ci doit être capable d'ajouter des Boutons à une ToolBar passée en paramètre, et recursivement pour les sous-frame
Cela test avec is pour savoir si ça hérite d'une TFrame ou d'une TFrameWithToolBar

La Fenêtre contenant la Frame appel cette méthode, passe sa ToolBar en paramètre, ensuite cela doit se faire tout seul !

Tes frames sont réutilisables ? il te faudra ajouter un objet de contexte, car dans certains cas les menus ajoutés seraient différents !
Si tes Frames ne sont pas réutilisables ? pourquoi des Frames ?

Tu dois pouvoir aussi faire un équivalent pour un TMainMenu !

Merci pour ta réponse, effectivement elle confirme mes recherches sur le net car je n’avais rien trouvé, d’où ma question sur le forum.

Mes TFrame ont 2 usages, un pour une gestion du code beaucoup plus simple car chaque frame à sa fonction et du coup l’unité est beaucoup plus légère en taille de code. Et l’autre effectivement, c’est de pouvoir réutiliser ces frames à plusieurs moment soit dans des Forms différentes ou de bien pourquoi pas dans des programmes différents.

D’après toi lors de la connexion à la Toolbar parent pourrait-on facilement trouver une méthode pour affecter le Parent des boutons et masquer la toolbar de la Frame enfant ? Les boutons seraient « juste » déplacé visuellement dans la toolbar parent?

Je vais m’auto-répondre, et changer de question du coup.

J’ai fait l’essai d’affecter le parent du bouton à la toolbar parent, et ça marche bien. Le soucis c’est quand je veux faire l’inverse c’est plus difficile.
En effet dans mon projet, une toolbar parent peut avoir plusieurs toolbar enfants. Du coup une fois les boutons ré-affectés, je ne sais plus à quel toolbar enfants ils appartiennent car le Owner des boutons ce n’est pas la toolbar mais la TFrame…

Donc ma question comment peut-on faire en mode conception pour que lorsqu’on pose un bouton sur par exemple un TCustomPanel (composant de base de ma TMyToolBar), le Owner soit le TCustomPanel et non le TFrame parent ?

Pour les Frames, il n'y aurait pas de ToolBar, juste une fonction qui permet de créer dynamiquement des TToolButton avec comme Parent (et\ou Owner) la ToolBar de la TForm ! Pas d'IDE !

modifier TToolButton.Parent fonctionne, comme c'est un TControl c'est normal, c'est juste la collections Buttons[] qui pourrait poser des problèmes (VA ? EListError ?)
Voir aussi RemoveComponent et InsertCompoment si tu veux absolument utiliser l'IDE !

Utilise Tag, tu mets dedans le Handle ou la référence de la Frame, il sera facile de les trier et de les retirer

j'ai maintenu des applications qui contenait des TToolBar, mais je ne me suis jamais intéressé plus que cela à ce composant, surtout que j'utilisais une TActionList (qui permettait d'avoir aussi l'action dans le MainMenu) donc souvent c'était plus pour offrir les fonctionnalités les plus courantes à portée de main !

Ton histoire de fusion me pose juste un problème de compréhension pour l'utilisateur, déjà lors d'un Merge de Menu MDI, certains utilisateurs sont perdus, si tu as une ToolBar, faudrait veiller que les Frame utilise des Icones différentes, sinon comment s'y retrouver si tu as des icones en double

Pour ton histoire de "l’unité est plus légère", c'est un long débat, si tu as un code de fenêtre lourd c'est souvent parce qu'il y a un mélange entre la présentation et le modèle (genre du SQL en plein milieu pour remplir une DBGrid), le MVC en Delphi, ce n'est pas habitué, c'est presque Anti-RAD comme méthode !
Pour moi, une Frame ou une Form devrait quasi vide, juste les EventHandler qui appelent une série de fonction d'un objet (controller) pour récupérer les données qu'elles doivent afficher !
J'ai trop souvent vu (et je le vois encore où je travaille), toute l'intelligence métier dans les fenêtres (insertion, règle de maj, contrôle de cohérence...), lors que tu fais une nouvelle fenêtre qui doit mettre à jour une série de table, tu copies-colles ou réécrit des passages entiers de code métier, une aberration car rendra les futures évolutions pénibles avec de fort risque de régression !

merci de ton aide, j’ai fait quelques essais et j’arrive à mes fins…

En ce qui concerne ton commentaire sur la séparation de VCL/objet métier je suis 100% d’accord avec toi. D’ailleurs je fais de nombreux composant d’affichage de graphe, et depuis quelques années, j’ai pris l’habitude de séparer tout l’aspect VCL de la fonction même du composant.