Salut les gens,
 
Voila je suis en train de faire un soft, j en suis qu au debut et il fait deja 774 lignes. J ai recement fait trois soft de chaqu un 2000 lignes et plus et c etait la mouise a maintenir.
 
J aimerai donc decouper mon programme en plusieur unites. J ai deja essayer mais je crois que je manque de methode car je suis devenu dingue mon soft marchait plus comme il faut.
 
Un exemple me ferait bien plaisir. J aimerai aussi comment proteger les procedures et variables
 
Merci d avance
 
@->--

En mettant un objet par unit tu réduis déjà pas mal à condition de faire de la programmation objet propre
Et pour faire ça proprement, il faut mettre le moins de code possible dans les unit des forms.
On ne devrait mettre là à peu près que ce qui concerne le visuel de la form elle-même.

Je pens equ il ne faut pas separer les codes tel que FormOncreate , destroy etc de l unite principale ?
comment ca se passe pour les declaration de procedure ?
 
 
@->--

bah pourquoi les séparer ?

 
D ou mon post ne pas separer les evenement OnCreate, OnDestroy et etc de l unite principale ! c est pas ce que t a voulu dire ?
 
 
@->--

bah dans le OnCreate/OnDestroy tu mets la gestion de la fenêtre, et à la création destructions des objets appartenant à la fenêtre, ou l'appel à des méthodes d'objets qui existaient déjà avant la fenêtre...

Ok.
 
Comment ca se passe pour les declarationw ? toutes les procedures sont declarer dans l unigte principale "so to speak" ?
 
@->--

je vois pas trop le rapport
 
T'as des objets, la fenêtre peut connaître et créer les objets, mais le max de traitement (tout ce qui ne concerne pas directement l'interface utilisateur) doit se faire dans les objets (qui sont dans des autres units) plutôt que directement dans les OnClick etc.
C'est assez abstrait, et pas évident à expliquer

 
Bah non y a rien de plus concret, une définition de classe max par unit, que ce qui touche à l'objet dans l'objet et pas des trucs bidons à la con comment un vilain programmeur pas organisé (donc une bonne analyse), et donc évidemment uniquement ce qui touche au visuel dans l'unité d'une form, aucun traitement lourd vu que tout ca doit se trouver dans de jolies classes ailleurs  
 
Et oui, c'est plus chiant que clic-clic, mais c'est propre

 
+1 ça sert à rien !!

Hum,  
J y vois pas trop clair dans vos explications. Mais bon a vous entendre ca va pas etre possible de reunir les evenements d un Tedit tous dans la meme unite ? right ?
En attendant j ai ecrit une unite qui s occupe d un traitement long et qui apparaissait plusieur dans mon prog. C est cool  j ai au moins economiser 100 lignes (commentaires inclus). La question que je pose est la suivante est ceque ca en vaut la peine de creer un nouvelle classe a chaque fois (disons a chaque unite que je vais ecrire). Car quand je ne fais pas de type je n ai pas le droit aux closes telle que public & private. Bon en ce moment toutes mes procedures sont en public donc ca change pas grand chose.
 
Merci    
 
@->--

Si tu mets la déclaration de procédure dans la partie "interface", elle est connue de tous ceux qui incluent la unit.
Sinon elle ne l'est pas.

Alors si je fais comme ceci ca pourrai fonctionner:
 

 
J ai pas delphi sous la main
 
@->--

non, parce que les événements des objets doivent être des méthodes (procédures de classes)
 
mais je vois pas pourquoi tu veux mettre les events dans une autre unit, c'est pas très logique...

C est juste pour savoir c est tout pour l instant. Les gros traitement pas grphic je fais une (ou plusieurs) unite(s) a part. Imagine le cas ou tous les compo visuels de la form ont tous leur evenements programmer ! merci l ambiance.
je sais que pour ce soft ca sera pas le cas. Mais bon je veux bien reunir tous les evenements ensemble mais bon dans une unit a part ca peut etre sympa.
 
@->--

bah à priori tu mets tous les events dans la unit de la form, puis de là tu appeles d'autres objets
mais vouloir mettre dans une autre unit les événements d'un objet c'est un peu bizarre

Si je comprends bien toi tu fais

 
? j ai bon ?
 
@->--

 
oué mais faut pas oublier que ton form n'est qu'une interface pour ton application, si tu fais de la programmation OO propre tu auras une jolie architecture d'objets qui n'ont rien de visuels pour traiter tout ce que peut faire l'application (y compris les options, etc, etc) mais si tu le comprends comme étant un objet cée dans ton form pour y foutre les fonctions ailleurs ca n'a aucun sens tu sais...
 
Si tu te penchais sur méthode?  

Ok je veux bien programmer proprement mais qu entends tu precisemtn par prog OO puisqu a apparament c est pas bon ce que je fais.
Un petit exemple ne me fera pas de mal je pense.
 
Merci en tout cas
 
@->--

 
heu il manque la déclaration de tform1 là
 
ou alors tu as pas compris ce que je voulais dire par procédures publiques ou non : public = déclarées dans interface, private = pas déclarées dans interface

 
J ai pas delphi sous la main c est pour ca.
En tout cas si vous avez un exemple c est mieux
 
@->--

 
mais ceci n'a rien à voir avec les événements des Forms...