hier, j'ai commencé à discuter sur "Interface à onglets MDI VS". J'ai demandé si je devrais continuer à développer mon application sous forme de MDI, ou dois-je intégrer les formes de l'enfant en feuilles d'onglets. Quelqu'un a pointé que je devrais utiliser des tframmes à la place ... Ma question est la suivante: pourquoi?
Qu'est-ce que les avantages d'utiliser des tfradames lors de l'intégration de la forme sur TFRAME? Jusqu'à présent, je ne le sais pas, la commutation ne nécessiterait que de réécrire certaines parties du code ...
(Je ne vais pas utiliser d'enrobage au moment de la conception de toute façon!)
Merci d'avance
7 Réponses :
Les cadres sont bons lorsque vous souhaitez répéter une "sous-forme" plusieurs fois dans une forme. Je ne les utiliserais pas pour l'interfaçage à onglets, car la forme intégrée est une meilleure solution pour l'utilisation d'interface MDI / onglets.
Veuillez fournir Toute raison Pourquoi une forme intégrée serait une meilleure solution qu'un cadre.
MGHIE, je ne discute pas avec vous, cependant - veuillez fournir une raison quelconque pourquoi pas ;) J'aimerais vraiment savoir pourquoi les cadres sont meilleurs pour une interface à onglets multiples?
Exactement ma pensée: qui irait pour des formes embarquées s'il pouvait simplement utiliser des cadres à la place? Les cadres sont tellement moins tracas. Et même si vous en avez besoin sous forme de formulaire plus tard, vous pouvez simplement créer un formulaire vide AD Ajouter le cadre avec Align = Alignient.
Les cadres manquent certains des gestionnaires d'événements disponibles sur les formulaires, par exemple. FormeCreate. Au lieu d'attribuer des événements, vous devez remplacer certaines méthodes protégées (par exemple créer ou après la création de formes de formidae). Cela peut être un léger désavantage, mais peut faire un code plus claire.
Peut-être que vous trouverez des réponses dans ce fil: GUI-DESIGN-FORMULT-FORMULT-FORMULT-VS-simulé-MDI-TABS-VS-PAGECONTROL
Répondre au commentaire pour donner une raison pour une raison pour laquelle utiliser des cadres:
Je considérerais que les cadres sont des blocs de construction de l'interface graphique, avec une combinaison de temps de conception de composants existants à des composants plus avancés. Avant que Delphi 5, on aurait utilisé un Ils vous permettent de vous concentrer sur développer exactement les fonctionnalités dont vous avez besoin et rien de plus. Fait à droite, vous pouvez ensuite les intégrer à des feuilles de contrôle de l'onglet, dans des dialogues modales ou modestes, dans des cadres enfants MDI et dans des cadres standard. Vous pouvez même ajouter plusieurs d'entre eux dans une forme - quelque chose que l'on ne ferait probablement pas avec des formes embarquées. Le but est que pour une réutilisation maximale, une approche en couches est souvent nécessaire et des cadres aident avec cela.
Un cadre est apte à incorporer de la part de la part. Un formulaire doit être adapté pour ne pas montrer une barre de légende et une bordure, normalement on remplacerait le OTOH, je ne sais aucun inconvénient d'intégrer un cadre qui incorporant une forme ne serait pas.
Il y a un commentaire concernant des événements tels que Considérez le cas des paramètres par utilisateur: dans Pour des objets contenus qui ne sont pas des composants et doivent être gérés de vie, il existe par exemple tcustompanel descendant avec les contrôles d'enfants et enregistré en tant que nouveau composant, prêt à être supprimé sur un formulaire. Les cadres permettent la même chose avec moins de tracas.
CreaRams () et ajuster le style de la fenêtre en conséquence. Il y a beaucoup plus de propriétés de formes dans l'inspecteur qui n'a pas de sens pour une forme intégrée. IMHO, il faut utiliser l'entité la plus élémentaire et la plus générique qui suffit. Un formulaire est juste beaucoup plus qu'un conteneur de contrôle pour l'incorporation.
Oncreate ou Onshow que les cadres n'ont pas. En fait, je considérerais qu'un autre avantage des cadres, car les gestionnaires d'événements n'ont pas de paramètres, de sorte que beaucoup de choses deviennent codées dur dans des formes, nécessairement.
Oncreate Il n'y a pas beaucoup d'informations disponibles, il ne cesse donc d'invariablement à l'aide d'une constante ou du nom du formulaire pour la section File Ini, ce qui le rend très difficile voire impossible de réutiliser la forme ou de créer plusieurs instances de celui-ci. Avec des cadres d'autre part, une méthode LoadSettings est la méthode évidente de le faire, et elle peut transporter les paramètres nécessaires. Le contrôle de cette façon est renvoyé à l'endroit où il appartient, au conteneur du cadre / forme incorporé. La réutilisabilité n'est possible que si le comportement peut être ajusté de l'extérieur.
après l'après-construction et Beforedtruction .
J'ai eu la même décision il y a quelques années pour l'une de nos applications, nous voulions que cela ait l'air des formulaires intégrés, j'ai d'abord utilisé les cadres et j'ai écrit une classe pour le gérer.
Plus tard, j'ai trouvé la composante TLMDDisplayForm de lmdtools , qui faisant des formes d'intégration à l'intérieur de la tâche très facile, elle a été réduite le code utilisé et nous avons plus de fonctionnalités.
L'un des objectifs principaux que nous avons changés des cadres aux formes a manqué quelques événements de Tform, comme: Oncrate, Onshow, Onactive que nous utilisons pour certaines tâches de nos applications, à côté de certaines propriétés telles que: ActiveControl et autres choses que je n'ai pas 't Se souvenir.
Si vous souhaitez aller avec des formulaires, je vous suggère d'utiliser lmdtools qui facilite la tâche Pour vous, à côté de la version de base est gratuite: -)
Pour les formes / cadres insérées dynamiquement, je préfère personnellement utiliser des formes incorporées sur des cadres. Plusieurs versions revenaient lorsque l'on éditerait un cadre réglé sur Alclient, le cadre redimensionnait entre les modifications et les commandes alignées spécifiques à la droite du cadre changerait de position. Lors de l'utilisation de formulaires incorporés, cela ne s'est pas produit, alors j'ai fait le commutateur. Je crois que cette question est maintenant corrigée avec les versions ultérieures de Delphi.
Je suis tout à fait d'accord avec les points MGHIE réalisés plus tôt en ce qui concerne l'incapacité de transmettre des informations au formulaire intégré via des événements de notification. Pour résoudre ce problème, j'entraîne généralement une série d'interfaces dans chaque forme intégrée pour la communication. Cela simplifie vraiment le code et permet une implémentation plus générique dans laquelle vous disposez d'un seul "conteneur" qui traitera de nombreux types de formes / cadres intégrés. Quelques exemples de ceci sont disponibles sur mon blog dans le cadre du cadre de l'assistant que j'ai conçu.
Cadre Utilisez la charge la plus rapide et sans délai lors de la création du cadre.
Mais le cadre doit être un parent pour l'intégrer. L'inconvénient de NO ONCREATE ou ONSHOW a été déclenché. Mais vous pouvez appeler avec le message pour déclencher l'événement Onshow comme celui-ci:
Mettez la section privée de la trame: puis créez le code comme celui-ci : espoir peut vous aider à envisager un cadre incorporé pour l'interface graphique pour interface graphique. Vous pouvez envisager de combiner avec Pagecontrol pour contrôler votre ouverture de cadre. manz
Je pense que les deux devraient être utilisés. Par exemple, j'ai un cadre "standard" comportant des composants DBNavigator, DBGRID et DataSource, qui est très pratique pour la navigation typique des données. Au lieu d'insérer de tels composants à chaque fois, j'insère une image qui a également la possibilité d'exporter ses données (avec JVCl: D) sur plusieurs formats ... mais je sais ce que je veux afficher au moment de la conception, alors je suggère un très Règle facile: si elle est connue au moment de la conception, utilisez des cadres, utilisez sinon des formulaires incorporés.
Cependant, gardez à l'esprit que les formes n'ont pas été conçues pour être intégrées. Utilisez-les comme donc, son non naturel (comme des états de vampire quand elle enterre sa fille de 80 ans et elle ressemblait à 30: D). La forme intégrée connaît peu de celle qui la possède et peut également supposer (logiquement) supposer que ce n'est pas intégré.
Complétant cela, un cadre est un composant, et donc, lorsqu'il est intégré (appartenant à) sous une forme, la forme sait à ce sujet et que le cadre sait sur la forme (peut utiliser ses méthodes et ses propriétés. Un incorporé peut également Faites cela mais nécessite un codage supplémentaire)
Peut-être que Embarcadero pourrait nous donner une main en créant une formule tempée ou une interface pour de telles fins
Cordialement, Alvaro Castiello