Discussion :

[bourdon]

bonjour tout le monde !!
voilà je cherche à créer un executable automatiquement. Je m'explique : j'ai une application de configuration et je voudrais que lorsque cette configuration est validée, construire l'executable qui en resulte. Alors ma premiere question est la suivante : comment créer un executable automatiquement sous Delphi ?
Ensuite se pose une autre question. En effet, il faut que cet executable prenne en compte des formulaires que j'ai crées suite à la configuration : donc comment lui spécifier les formulaires à prendre en compte ?
Voilà mes "quelques" questions, j'avoue que je n'ai pas du tout d'idées pour aborder ce probleme donc hesitez pas : toute contribution est la bienvenue !!! merci a vous

[Mac LAK]

Tu n'aurais pas plutôt intérêt à développer une application générale, et à prendre ta configuration en compte via un fichier .INI ??? Ta méthode me semble quand même un chouia bourrine !!!

Sinon, pour compiler une application Delphi, tu peux utiliser la ligne de commande et un makefile, mais vu que je n'en utilise déjà pas en C/C++, je te laisse imaginer ce que j'en pense avec Delphi...

Pour tes formulaires, tu les as créés comment, exactement ?

[bourdon]

en fait ce qui ce passe c'est que je crée une application qui peut contenir 1 à 10 formulaires et dont les formulaires changent a chaque fois mais sont crées selon 1 type prédéfini (il y a 3 types différents au total). Or ces formulaire sont configurés selon les données d'une base de données. C'est peut etre une methode assez bourrine mais en fait vu mon niveau je pense pas pouvoir faire différemment... quant a utiliser les fichiers .ini j'avoue ne jamais avoir tenter et etre un peu juste en temps pour pouvoir le faire maintenant...
Quant aux formulaires en fait je crée une instance de chaque type à chaque nouveau formulaire, en leur donnant un nom différent. Je pense que ca marche vu que je suis encore en theorie mais j'ai deja tester de créer en fonction de mes besoins les formulaires et cela marche sans problemes mais j'ai un doute au niveau du nom du formulaire donné. Au pire je peux créer 10 formulaires différents ou je positionnerais tous les elements que je voudrais. Ce point la ne me pose pas trop de problemes : j'ai des idées.
Ce que je n'arrive vraiment pas à conceptualiser c'est cette creation d'exe qui au depart n'existe pas. Il faut qu'elle puisse charger le premier formulaire et puis c'est tout. Mais comment le faire ???

[Mac LAK]

en fait ce qui ce passe c'est que je crée une application qui peut contenir 1 à 10 formulaires et dont les formulaires changent a chaque fois mais sont crées selon 1 type prédéfini (il y a 3 types différents au total). Or ces formulaire sont configurés selon les données d'une base de données. C'est peut etre une methode assez bourrine mais en fait vu mon niveau je pense pas pouvoir faire différemment... quant a utiliser les fichiers .ini j'avoue ne jamais avoir tenter et etre un peu juste en temps pour pouvoir le faire maintenant...

Cas typique de l'application devant être pilotée par un fichier INI, avec création dynamique de composants et/ou adaptation des fiches en fonction de données externes...

Quant aux formulaires en fait je crée une instance de chaque type à chaque nouveau formulaire, en leur donnant un nom différent. Je pense que ca marche vu que je suis encore en theorie mais j'ai deja tester de créer en fonction de mes besoins les formulaires et cela marche sans problemes mais j'ai un doute au niveau du nom du formulaire donné. Au pire je peux créer 10 formulaires différents ou je positionnerais tous les elements que je voudrais. Ce point la ne me pose pas trop de problemes : j'ai des idées.

Mais tu ne réponds pas à ma question : sous quelle format sont tes formulaires ? Des .DFM ? Des .RES ?

Ce que je n'arrive vraiment pas à conceptualiser c'est cette creation d'exe qui au depart n'existe pas. Il faut qu'elle puisse charger le premier formulaire et puis c'est tout. Mais comment le faire ???

C'est ton application de configuration qui devra créer l'exécutable, c'est à dire appeler le compilateur Delphi pour créer l'exécutable final... Il faudra donc modifier le source du fichier principal pour lui donner le nom de la fiche primaire.
Ce qui suppose aussi que tu vas devoir installer Delphi sur chaque poste où sera installée ton application : c'est pas gagné au niveau licence...

Je pense que tu as fait une grosse erreur de conception, sur ce coup...

[bourdon]

en fait a force d'y reflechir je pense avoir trouvé une solution intermediaire : avoir au depart mon exe de configuration, 10 formulaires deja crées mais pas complets (qui seront mis en place completement par l'exe de config) et un autre exe qui chargera le premier formulaire. en suite je m'arrange pour savoir a chaque fois que je quite un formulaire si un autre formulaire doit suivre. Ainsi pas de création d'exe a faire vu qu'elle est deja crée et vu qu'il y a au moins 1 formulaire a charger ca marche.. enfin je pense !!
mais alors il y a encore besoin de compiler ? normalement non vu que le nom du premier formulaire ne change pas (formulaire_1 par exemple)...

Je crée des formulaire .dfm : tu pense que je vais avoir un probleme ??

tu peux m'en dire plus sur la methode du fichier .ini ???
Merci a toi
ps : t'inquiete la conception n'est pas terminée !! elle peut encore largement bouger... mais assez rapidement

[Mac LAK]

Je crée des formulaire .dfm : tu pense que je vais avoir un probleme ??

Oui, étant donné qu'ils doivent être compilés par Delphi (le résultat est dans les ressources de l'exécutable) pour pouvoir être utilisés, ça va te poser un gros problème...

tu peux m'en dire plus sur la methode du fichier .ini ???

En gros, un fichier INI, c'est un ensemble de sections, contenant des clés. Chaque clé est associée à une valeur, dont le format "normal" est du texte (String), mais que Delphi sait lire de plusieurs manières possibles (à toi de te rappeler le "type" de chaque clé, bien sûr).
Schématisé, c'est un ensemble de casiers indépendants (les sections), contenant des variables (clés) possédant une valeur (la valeur, justement). Tu mets dedans ce que tu veux.

Plus d'infos dans la : http://delphi.developpez.com/faq/?page=fichiersini

C'est super simple, tu verras. Je te conseille de regarder l'aide Delphi des classes TMemIniFile et TIniFile.
Les deux permettent aussi bien de créer que de lire les fichiers INI.
Personnellement, je préfère utiliser TMemIniFile, c'est le plus performant des deux, mais si c'est juste pour une initialisation, ça ne changera pas grand-chose.

Merci a toi

De rien. Bonne lecture, et bons essais.

[bourdon]

Si j'ai bien compris un fichier ini me permet de stocker les parametres de mes composants separement de la form ce qui evite d'avoir a compiler a chaque lancement vu que le formulaire aura deja ete compilé et prend en compte le nouveau fichier ini crée par la configuration. Ainsi tous les parametres sont ecrits dans le fichier ini par section et chaque section correspondrait pour moi a un composant. Mais cela suppose d'avoir deja créer tous les composants de la form non ? Si c'est cela alors je pense avoir compris et c'est vrai que c'est beaucoup plus simple !! mais je ne connaissais pas...

Par contre tu peux m'en dire un peu plus sur la difference entre les .dfm et les .res ??

merci de prendre du temps pour m'aider !!!

[Mac LAK]

Si j'ai bien compris un fichier ini me permet de stocker les parametres de mes composants separement de la form ce qui evite d'avoir a compiler a chaque lancement vu que le formulaire aura deja ete compilé et prend en compte le nouveau fichier ini crée par la configuration.

C'est bien ça. En général, je lis mes fichiers INI dans le OnCreate de ma fiche principale, qui peut être une fiche "Veuillez patienter, initialisation en cours..." si tu n'as vraiment pas de "fiche principale"... N'oublie pas de la cacher (et pas de la fermer !!) lorsque tu actives ta "vraie-fausse" fiche principale après.

Ainsi tous les parametres sont ecrits dans le fichier ini par section et chaque section correspondrait pour moi a un composant.

C'est bien ça. Tu peux y mettre le libellé des TLabels, les Hints, des booléens pour cacher (ou non) des composants, des panels, des TTabSheets, des booléens généraux de "contrôle", des noms de tables, etc, etc, etc.

Mais cela suppose d'avoir deja créer tous les composants de la form non ?

Oui, mais c'est déjà fait, dans ton cas... Il faudra simplement "conditionner" tes fiches suivant le contenu du fichier INI : par exemple, refuser d'afficher la fiche n°4 si le booléen correspondant vaut False... Tu vois le topo ?

Si c'est cela alors je pense avoir compris et c'est vrai que c'est beaucoup plus simple !! mais je ne connaissais pas...

Pourtant, les fichiers INI sous Windows, c'est connu !!

Par contre tu peux m'en dire un peu plus sur la difference entre les .dfm et les .res ??

Très simple : la même différence qu'entre un .PAS et un .EXE !!
Un .DFM est compilé au sein d'un .RES, mais ce dernier ne contient pas que des fiches compilées : il contient des icônes, des chaînes, des données, etc, etc. Tout comme un .PAS produit bien une partie d'un .EXE, mais tous les .EXE ne proviennent pas d'un .PAS ! ;-)

[Clorish]

JE suis aussi en train de bosser sur un projet qui permet de creer des progrmmes tout seul comem toi.
Moi mon but et de creer un programme qui puisse etre configure mais pas sous forme de fichier 'ini' ou autres car une fois configuré il ne dois jamais changer (et c'est aussi une question de securité)

Ce que je fais c'est que je cree un projet de base et je regrouppe toutes mes initialisation ou du moins les codes qui doivent varier dans des constantes ou dans des procedures simple.

Le but etant de generer 2/3 fichier maxi (pas trop quand meme) avec jsute la declaration de constantes, implementation de 2/3 procedures.

Voir meme uniquement le code interne d'une procedure.

Dans mon code de base, j'inclu ces fichiers sous formes de .Inc

Dans mon arborescence de projet, je regroupe les Inc dans un rep particulier "config" ou "Includes".

Ensuite, je genere une ficheir de Ressource .Res qui contient tous les ficheirs sources de mon projet de base (sans les inc !!)
J'inclut ce ficheir de ressource dans mon prog "generateur d'executable" qui se charge de charger chacun des fichiers ressources dans un TRessourceStream puis avec un SaveToFile, je reconstruit sur le HDD du client le projet de base.
Reste ensuite plus qu'a creer les 2/3 fichiers Inc dans le repertoire souhaité avec les memes noms que specifié dans le code (et en faisant attention a la syntaxe ;p ) puis executer le compilateur Borland.

PAr contre il est fort possible que l'on doivent fournir aussi certains paquets/DCU des unites borland pour permettre la compilation mais cela est un probleme unique a toutes tentative de compilation sur un poste ne possedant pas Delphi.

On peut eventuelement court circuiter ce probleme en definissant le projet comme "compiler avec des paquets d'execution" ce qui nous permet peut etre de se passer de certains DCU.

Sinon on recompile juste une Dll sur laquelle s'appuie le programme de base pour se configurer. A condition bien sur que la Dll ne s'appuie que sur tres peut d'unitee Borland :/

[bourdon]

Pour les fichiers ini c'est vrai que sous windows c'est plutot courant mais je n'avais jamais approfondis réellement la chose et puis je n'avais pas penser à les utiliser comme cela. Pour moi ce sont des fichiers que l'on utilise pour des données plutot statiques (login , mot de passe...). Il faut maintenant que je fasse une architecture de ce fichier en séparant à la fois les différents formulaires et leurs composants. Ca c'est un peu de rigueur et c'est bon cependant il me reste une derniere question : le fait d'utiliser un fichier ini va ralentir de beaucoup mon application ou seulement au debut ?

Pour Clorish, mon programme est un peu différent du tien : le mien chargera au moins un formulaire et au plus 10 mais sa configuration changera à chaque utilisation. Ainsi apres un phase de configuration je veux pouvoir montrer tel ou tel type de formulaire avec tel ou tel composant. Et puis mes procedures ne changent pas ce n'est que l'apparence qui change. Mais ton appli a l'air bien sympa !!!

En tous cas merci a vous deux !!!

[Mac LAK]

le fait d'utiliser un fichier ini va ralentir de beaucoup mon application ou seulement au debut ?

Un peu seulement, et uniquement au début. N'oublie pas qu'il y a toujours forcément une conversion chaîne -> type final (entier, booléen, etc...), en plus de la lecture/analyse... Ca va très vite, mais ça prend un peu de temps quand même... Si t'es très mauvais et que tu as beaucoup de clés, ça va peut-être prendre une seconde au démarrage, et encore : je pense que je suis très pessimiste.

Si tu dois "piocher" en permanence (ou une seule fois, mais sur beaucoup de clés) dans le fichier INI, utilises un TMemIniFile qui conserve tout en mémoire (et donc ne fait pas d'accès incessants au disque dur), et, éventuellement, recopie les valeurs "converties" vers des variables globales de ton application de manière à ne pas être obligé de les (re)convertir une deuxième fois.

Dans ton cas, tu auras donc à livrer :
1) Le binaire "général", capable de tout faire.
2) Le binaire "de configuration", qui sera capable de générer les .INI pour le premier. Ca peut aussi être un module (=un TTabSheet ou une fiche, par exemple) du premier binaire, ça ne coûtera au pire qu'un redémarrage de l'application. Ca peut même être dynamique si tu centralises bien la lecture de ton .INI !! ;-)

Note : Pour chaque valeur lue d'un fichier .INI, il y a une valeur par défaut, que les fonctions renvoient lorsque la clé n'existe pas. Je te conseille de bien réfléchir aux valeurs par défaut que tu vas mettre, histoire de ne pas te retrouver avec une application 100% verrouillée (=> tu risques de ne même pas pouvoir la fermer, ou ça risque de planter dur), ou au contraire 100% débridée... Fais toujours un essai sans aucun fichier INI, histoire de vérifier ce point, OK ?

En tous cas merci a vous deux !!!

De rien.

[bourdon]

en fait je vais essayer de reduire au maximum les echanges entre le fichier ini et l'application je pense que j'y stockerais essentiellement le type de mes formulaires et que selon ce type j'appelerais une procedure qui mettra en place mes composants (qui seront deja crées) pour les rendre visible ou non.
Quant au petit temps d'attente au debut il ne me gene pas mais merci pour tes precisions sur la conversion chaine->type final et pour les valeurs par defaut.
Merci encore pour tout

[Mac LAK]

Du coup, tu nous fais un petit ? ;-)