Discussion :

[LaurentC33]

Bonjour !

Je travaille sur un projet un petit peu complet (pour bien me faire la main avec delphi).

Ce projet comporte plusieurs parties : exemple : clients, contacts, equipement, etc...
J'aimerais savoir si il est possible d'au lieu de créer une application avec un form et tout coder dedans, de scinder chaque partie dans des unités différentes.
Par exemple un onglet dans l'application principale qui a chaque clic, charge les unités...Si quelqu'un a des infos ou un tuto sur ça, c'est sympa

[djiga4me]

Bonjour,

Vous pourriez créer plusieurs Form, et y mettre chaque partie homogène. Elles communiqueraient alors avec ta fenêtre principale.

Vous pourriez aussi mettre toutes tes fonctions/procédures communes dans une fichier Unit et l'ajouter dans les uses de votre unité principale.

Si cela ne vous aide pas tant que ça, pourriez-vous reformuler ou être plus explicite.
Merci.

[ShaiLeTroll]

J'aimerais savoir si il est possible d'au lieu de créer une application avec un form et tout coder dedans, de scinder chaque partie dans des unités différentes.

C'est un peu le principe du uses : Création d'un fichier unité

Une unité est un module de code Delphi compilé séparément.
Delphi emploie les unités pour plusieurs raisons.
Chaque fiche possède sa propre unité et la plupart des composants (ou des groupes logiques de composants) possèdent aussi leurs propres unités

Par exemple un onglet dans l'application principale qui a chaque clic, charge les unités...Si quelqu'un a des infos ou un tuto sur ça, c'est sympa

Il n'y a de "chargement" des unités
C'est juste des inclusions de fichier par d'autres !

tu as Le Guide Delphi par Frédéric Beaulieu

Sinon, les grand classique comme le MVC qui de donnera une idée sur les concepts de base pour "scinder" le code

[LaurentC33]

Désolé pour mon manque de clarté

En fait j'ai un form principal qui contient des ongliets (TTabControl par exemple)
et chaque contenu par onglet serait en fait une autre unité (form ?) qui sera chargé dynamiquement.
Comme ça je crée mes forms séparément et non dans le form principal

[djiga4me]

Sauf si vous mettez chaque contenu d'un TabControl dans un Frame et vous créez dynamiquement au besoin. Mais je trouve cela plutôt "barbare" dans ce contexte. ICI et ICI.

Comme a dit ShaiLeTroll, utiliser autrement les Uses, écrire son code dans une unité et l'inclure dans les uses de la Form principale.

[ShaiLeTroll]

Pour le TTabControl, tu peux utiliser soit
- des TFrames construites et ajoutés en DesignTime
- des TFrames construites en DesignTime mais ajoutés en RunTime (propriété Parent)
- des TForm construites en DesignTime dont l'on change la propriété Parent en RunTime

J'ai pour ma part utilisé ce dernier cas, avec au moins 20 onglets, certains pouvant ouvrir la même fenêtre

Tu peux aussi utiliser un TPageControl, là ta fenêtre aura tous les éléments visuels mais tu peux créer des unités (sans fenêtre) qui contiendront le code intelligent

L'erreur classique c'est coder tout directement dans le OnClick ...
il y a la partie affichage, il semble logique quel y soit !
faire un controleur du MVC demande des efforts qui compliquent le développement, le Delphi et on IDE n'est pas forcément fait pour cela !

La partie métier comprenant la vérification de la cohérence de données, il est préférable de l'isoler pour pouvoir la réutiliser dans d'autre écran
Ainsi, peu importe par où l'on passe, c'est toujours les mêmes règles qui s'appliquent !
Cela demande juste de la rigueur !

Enfin, la gestion du stockage de données, peut être aussi déporter et unifier toujours dans l'idée de réutiliser le code !
Un code réutilisable doit être facile d'accès, doit avoir un périmètre d'action limité à un seul domaine, DOIT être documenté et ROBUSTE !

[LaurentC33]

Tu as tout compris

des TForm construites en DesignTime dont l'on change la propriété Parent en RunTime

Ca me plait bien cela

Je vais tester !

[LaurentC33]

Bon j'ai testé un truc vite fait ce soir

Dans mon Form principal j'ai rajouté un page control et la procédure suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
procedure TMainForm.AddForm(tabForm : TForm);
var
  tabSheet : TTabSheet;
begin
    tabSheet := TTabSheet.Create(PageControl1) ;
    tabSheet.PageControl := PageControl1;
    tabForm.Parent := tabSheet;
    tabForm.Align := alClient;
    tabForm.BorderStyle := bsNone;
    tabForm.Visible := true;
    tabSheet.Caption := tabForm.Caption;
end;

Et j'ai crée d'autre Form, et a leur événement create :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
procedure TPage1Form.FormCreate(Sender: TObject);
begin
MainForm.AddForm(Page1Form);
end;

Du peu que j'ai testé ça à l'air pas mal

[SergioMaster]

Bonjour,

tu peux aussi utiliser :
- soit une fenêtre MDI (menu principal et 'bureau') et des fenêtres enfants
- soit le docking si tu veux des onglets , c'est presque la même chose que le MDI à quelques exceptions près : la gestion de fusion de menus par exemple

le docking correspond pratiquement a la dernière technique que tu as utilisé
voir ici cependant le docking n'est pas possible avec toutes les versions de Delphi

[Pascal Jankowski]

Pour résoudre ce problème de fenêtres embarquées il faut prendre en considération plusieurs points (je n’en détaillerai que deux qui sont les plus importants).

Premier point, se poser la question de savoir si les fenêtres qui vont être affichées sont toutes indépendantes les unes des autres et si l’information particulière à une fenêtre peut également se retrouver dans une autre fenêtre (cas des doublons).

Prenons l’exemple d’une gestion commerciale où l’on désire gérer la facturation. De façon naturelle on va construire deux tables (les documents, les lignes de document). Il existe une relation 1-n entre respectivement les tables Document et Lignes.

Par ailleurs, dans notre applicatif il est intéressant d’afficher une première fenêtre contenant la liste des factures, puis en double cliquant sur une facture ouvrir une nouvelle fenêtre avec le contenu de la facture (entête, pieds et corps de document, ce dernier composé des lignes d’articles facturés).

De même on peut étendre le principe et permettre d’afficher autant de factures que l’on désire à condition qu’elles ne soient ouvertes qu’une seule fois voire plus permettre l’ouverture d’une nouvelle fenêtre vierge pour créer une nouvelle facture.

Partant de ce principe on constate que l’on ne peut avoir qu’une seule fenêtre contenant la liste des factures (respect du « non doublon ») et une multitude de fenêtres toutes uniques contenant le détail d’une facture.

Cela conduit donc à la nécessité de construire une liste permettant le suivi des fenêtres qui sont ouvertes afin :
- d'éviter d’ouvrir une fenêtre déjà ouverte
- de refermer toutes les fenêtres si la liste vient à être refermée
- de suivre les fenêtres qui ont eu une modification pour être en mesure d’interroger l’utilisateur pour savoir s’il désire éventuellement les enregistrer. Et éventuellement, gérer l’abandon de fermeture.

Il faudra disposer d'une liste pour chaque formulaire liste ouvert.

Il faudra également gérer la prise de focus des tabSheet à la fois avec la souris (naturel) mais également par le code.


Le point numéro deux concerne le problème de factorisation. En effet, le principe exposé ci-dessus (liste maitre et fiche détail) peut être étendu à toutes les données qui seront gérées dans l’applicatif (Par exemple pour les articles, les clients etc…).

On se retrouve donc à gérer par exemple de la même façon la liste des documents et la liste des clients ou des articles. Il ne faut pas faire du cas par cas mais factoriser en fournissant en paramètre au procédé imaginé la table qui devra être traitée.

Cela signifie qu’il faut développer dans un formulaire ancêtre, les
comportements généraux puis dériver celui-ci pour chacun des cas rencontrés (documents, articles, clients…).

On peut également prolonger la réflexion au sujet des fiches et aussi à des fiches ne répondant pas au critère décrit ci-dessus (exemple fenêtres emportant des traitements statistiques ou des données de configuration).

Le problème qui te préoccupe est un problème très complet qui si il est parfaitement maîtrisé et si, de plus, tu en as une bonne vision te permettra deux choses importantes.
Créer un applicatif agréable à utiliser (non déroutant pour l’utilisateur final) de plus il sera robuste et plus simple à maintenir.

Je peux te mettre à disposition un exemple mais il fait appel aux composants DevExpress et aux Instantobjects, il te sera difficile de le compiler si ces composants ne sont pas installés.