Discussion :

[petitprince]

Bonjour à tous, me revoilà !
Merci pour toutes vos réponses, je vais aller les tester de suite....Mais j'ai préféré vous répondre avant !
En tout cas, vraiment merci....
Je regarde le tout et pense à rajouter résolu si c'est bon !!!

[Sub0]

Pour info, je cherche le moyen d'enregistrer des listes de clients dans un seul fichier... L'avantage avec la méthode que j'ai proposé, c'est qu'on fait le formulaire de saisie et les fichiers de données qui vont avec en même temps. Cette méthode me simplifie énormément la vie pour concevoir des programmes de saisie de données... Si tu veux, je te tiens au courant, à+

[petitprince]

Oui merci je veux bien être tenu au courant !!
Bon j'ai regarder un peu tout ca, mais ..... Ca ne comble qu'une partie du problème: je connaissais la technique du WriteComponent, et à vrai dire, c'est une bonne méthode, mais.... avec 1000 Clients dans mon carnet, le fichier pèsera combien au final ? Bon je matte la méthode de Waskol.....

En tout cas merci sub0, j'aime beaucoup ce que tu fais, notement au niveau du son ...

[Sub0]

c'est une bonne méthode, mais.... avec 1000 Clients dans mon carnet, le fichier pèsera combien au final ?

Tu regardes ce que pèse une fiche vierge que tu multiplies par 1000 sans oublier d'ajouter la taille des données. Le formulaire de ma démo pèse 1,41 ko. Tu devra donc ajouter 1Mo pour 1000 clients, ce n'est pas beaucoups je trouve par rapport au gain de temps de développement et la facilité de modifier le formulaire, sans compter toutes les fonctionalités qu'apporte cette méthode... De plus, tu peux envisager de compresser les fichiers à un très bon taux...

En tout cas merci sub0, j'aime beaucoup ce que tu fais, notement au niveau du son ...

Cela fait un moment que je ne programme plus le sample. Mon dernier code était l'extraction des pistes des CD audios et l'affichage des fréquences d'un sample (vumètre à barres). Je travaille aujourd'hui plus sur la réalisation d'un tchat pour mon jeu d'échecs, l'accès aux bases de données avec Delphi via des scripts PHP (tutoriel), et un espace membre sécurisé en PHP.

[petitprince]

Ok.....
Moi je bosse sur la réalisation d'un "after effect", non open source, et sur un autre projet, lui open source, où je recherche du monde : DUT , Delphi Universal Tools, soft pour créer des composants en run time, des List, Des Setup d'installation, des structures de fichiers, ... enfin tout pour faciliter le dev de grosse applications.... Mais là je suis hors sujet...

J'ai testé la méthode de Waskol qui est très bien, mais je comprend pas son unité Carnet, en même temps j'ai la tête dans le seau....
Et je ne peut stocker d'image....
Donc je vais bidouiller le tout, et on verra laquelle des solutions je prendrai...
Je vous tiens au courant et n'insert pas le tag résolu, au cas ou waskol repasserai par ici, où d'autre
A+

[neilbgr]

Salut à tous,

Il y a la possibilité de penser objet aussi.
Avec Delphi, Pascal Objet, ça tombe plutot bien.

Le problème de persistance, en OO, peut se traiter d'au moins 2 manières :

• Base de donnees
• Persistence (Sérialisation en C#, reflexion en Java, ...)

D'après les posts précédents, la solution base de données n'est pas souhaitée. Soit.

Reste quand même à explorer la piste de la persistance.
Il faut savoir que Delphi mets a disposition une mécanique qui permet de faire persister et de recréer des objets. Cette mécanique se nomme RTTI.
Au lieu et place de record, qui sont la technique classique en procédurale (en pascal, en C, ...), il suffit de déclarer des classes qui héritent d'au moins TPersistent. Comme son nom l'indique, tout objet héritant de près ou de loin de TPersistent, pourra passer dans la mécanique RTTI.
Puisque on peut sauver et charger un objet avec RTTI, une liste d'object a faire persister consiste seulement à une boucle for et faire la persistence de chaque item.
Je ne donne pas de solution directe, je pense que sur le net le sujet est bien traité, et aussi la lecture de la VCL ou bien (par exemple) du code du TGlScene (des compos GlScene bien sur) aident fortement à comprendre ce sujet.

Donc les mots clés pour des recherches sont :
Delphi RTTI TPersistent TStream.SaveComponent TStream.LoadComponent

[Laurent Dardenne]

Voir aussi :
http://delphi.developpez.com/cours/c...DataSetObject/

[petitprince]

Houla .... C'est un peu compliqué tous ca, et de plus, je ne cherche pas vraiment à stocker des composants entiers, sauf si j'y suis contraint....

[neilbgr]

mais ce n'est pas une contrainte !
Au contraire, c'est fait exprés pour ça !
De plus, que ce soit 3 strings dans un record, ou 3 property en published dans un objet, y a pas grande différence sauf la possibilité d'utiliser des concepts Orienté Objets telle la persistance !!!

C'est très instructif, perenne, très effiace et beaucoup plus souple que persistence à la main.
Une petite recherche sur le net, et je tombe sur :
http://nono40.developpez.com/sources/source0062/
http://www.delphipages.com/news/detaildocs.cfm?ID=145

Le 2eme lien donne une solution intéressante: l'utilisation de TCollection/TCollectionItem. Le coup du TListProxy sert juste à mettre en boite l'appel à la mécanique RTTI (via TStream.ReadComponent TStream.WriteComponent )

Une fois qu'on a compris et utilisé ces concepts, on se demande comment on faisant avant tellement c'est vraiment puissant et pas si compliqué qu'on pourrait le croire...

[neilbgr]

Bon, je m'y suis collé, en moins de 3h je vous propose cette solution :
ci-joint

Ceci est une utilisation de TCollection / TCollectionItem.
Mais on peut très bien utiliser le couple TComponent / TComponentList et du coup se payer le luxe d'avoir des items de natures différentes.

Vous remarquerez que la persistance se fait dans les actions actChargerRepertoire et actSauverRepertoire, et ce, en très peu de lignes de code.

Est-ce que cela répond à Sub0 et petitprince ?

@petitprince :
Il vaut mieux éviter de jouer aux pointeurs avec des outils OO comme Delphi...

@Sub0 :
Il vaut mieux éviter de mélanger couche graphique (IHM), des données, et de la persistence... même pour une appli test...

[Sub0]

Merci à tous !
Je suis enfin arrivé à obtenir ce que je voulais (avec de la persévérance).
Je vais tout de même étudier la solution proposée par neilbgr.

Il vaut mieux éviter de mélanger couche graphique (IHM), des données, et de la persistence... même pour une appli test...

En tous les cas, c'est très pratique comme méthode : Cela me permet de modifier le formulaire d'édition sans avoir à toucher une seule ligne de code. Bien entendu, cette démo ne s'applique pas à tous les cas...

[EDIT]
neilbgr : A la compilation de ta démo, Delphi 6 me retourne ce message :
[Erreur fatale] UClientCollection.pas (109): Impossible de créer le fichier de sortie 'X:\Dcu\UClientCollection.dcu'

[neilbgr]

ce n'est rien du tout... simplement la configuration des chemin de sortie dans Options de projet... il suffit de supprimer les chemin x:\bin et x:\dcu
Vraiment, ca me ferait plaisir que t'essaie de le compiler et que tu vois ce que cela donne. Dis-moi ce que tu en penses ! (je me suis pas coucher a 1h00 pour des prunes ! )

[neilbgr]

En tous les cas, c'est très pratique comme méthode : Cela me permet de modifier le formulaire d'édition sans avoir à toucher une seule ligne de code.

C'est ton point de vue... certes c'est pratique, mais perso je trouve pas ça correct (on mélange IHM données, et persistence). En tout cas, pas pour un développement un minimum professionel et perenne.

[Sub0]

Superbe !
Cela est légèrement plus compliqué pour modifier l'éditeur (ajouter de nouveaux types de champs par exemple) mais en contre partie, on gagne 1691 octets par client. J'ai une question: A quoi servent les boutons Valider et Annuler ? Je ne saisis pas leur nécessité...

En tous les cas, un grand merci pour ton travail, j'apprécie beaucoups, je ne l'oublierai pas !! C'est même dommage que je suis arrivé à solutionner mon problème, c'est mal tombé.

[EDIT]

C'est ton point de vue... certes c'est pratique, mais perso je trouve pas ça correct (on mélange IHM données, et persistence). En tout cas, pas pour un développement un minimum professionel et perenne.

Ce qui m'intéresse surtout, c'est obtenir un code le plus simple possible et la rapidité / facilité de développement donc un formulaire de saisie rapide et facile à adapter selon la demande du client. Pour ce qui est de la qualité, je ne suis pas sûr que le client fasse bien la différence... et moi non plus d'ailleurs ! Bref, je pense qu'il ya des avantages et des inconvéniants dans les 2 solutions mais je pense aussi qu'il ne faut pas présumer que l'une et plus "pro" que l'autre car cela dépend de ce que l'on recherche comme fonctionalité finalement. Si tu veux bien, argumente un peu plus ton point de vue.

ps: Je compte ajouter une compression / décompression des fichiers avec une en-tête pour éviter les problèmes de compatibilité.

[neilbgr]

Valider et Annuler te permettent de modifier une fiche et de seulement la valider quand en cliquant sur Valider (ou en changeant d'onglet). Annuler permet de remettre les données de la fiche courante dans l'editeur.
A vrai dire ces actions peuvent être cachées car pas indospensables.

Tiens, je joints une MAJ qui corrige deux petits trucs.

[Sub0]

C'est vraiment du beau travail.
Je n'ai rien à redire, ça marche au poil !

Un grand merci.

[EDIT]
Oui, tu as raison, c'est tout de même plus pro comme solution
Adopté !

[neilbgr]

mais en contre partie, on gagne 1691 octets par client.

Effectivement, car la raison est que tu sauvegarde plus d'infos que tu en as besoins. Si tu regardes tes fichiers, tu verras que tu TOUTES les propriétés published des controls que tu utilises. Or il te suffit que d'une souvent par control. Ensuite, le but est quand meme de résoudre le problème de petitPrince ! Donc ce que je propose permet de répondre à vous deux.
Evidement, on est bien d'accord, il n'y a pas LA Solution.
La tienne est défendable, elle est très RAD.
La seule chose qui me gène, c'est de faire persister l'IHM pour des données. Pour être plus clair, si au niveau de l'interface ça se complique sérieusement, ca ne fonctionnera plus. Maintenant, si on est certain que cela restera des simples edit ou mémo, pourquoi pas.

En tout cas, c'est un bon cas d'école, notament pour petitPrince.

[LadyWasky]

Dites qu'elle pue ma solution, personne n'a jeté un oeil dessus.

- c'est carrément un système SGBD monofichier construit à partir d'un TStringList ET compatible avec Delphi Standard.

- Ca ne sauvegarde que l'information utile des champs, pas les composants avec, comme si on sauvegardait tout dans un fichier csv donc, ni plus ni moins.

[Sub0]

Waskol: En ce qui me concerne, je pense que ta solution répond exactement au problème de petitprince. Pour simplifier mes développements, je cherchais une méthode plus "directe" et vraiment modulable. Ça n'a rien à voir, alors ne crois pas que l'on n'est pas remarqué ton code, loin de là.

[LadyWasky]

Ha bon... parce que je vous vois chercher, chercher, chercher...