cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 2023
-
11 août 2008 à 14:25
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 2023
-
12 août 2008 à 09:18
Bonjour,
Pour mon programme je voudrais faire un système de mise à jour.
Je pensais à faire une DLL, mais on arrive à ma question.
Quand on provoque la fermeture d'un process, la DLL qui était en cours d'utilisation est toujours utilisable ?
Je m'explique.
Je voudrais que le système de mise à jour ferme automatiquement le programme donc l'EXE afin de le mettre à jour, mais je sais pas si la DLL de mise à jour continueras de fonctionner ou non.
1)Une DLL est une librairie dynamique : Elle est utilisable par plein de process. Un process ne fait que l'utiliser. En fermant ce dernier, on intervient absolument pas sur la dll. Le pire qu'il puisse t'arriver c'est un beug lors de la fermeture de ton process mais ta DLL elle sera toujours utilisable.
2)Par contre si ta question est de savoir si la fermeture de ton application va provoquée l'intérruption des processus en cours de ta DLL (dans ton cas téléchargement), la réponse est non : Tu fermes que ton application, en aucune facon tu interviens sur ta DLL.
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 20234 11 août 2008 à 16:59
J'avais en effet mal posé ma question et je parlais en effet du petit 2.
Par ce que j'ai fait le test et quand je ferme la fenêtre principale (le fichier .EXE), automatiquement la fenêtre ouverte par la DLL (se trouvant dans celle-ci) est automatiquement fermé.
Que cela soit le 1), le 2), ou ta question (apres traduction ), tout s'explique avec ces 2 lignes de codes
Hdle:=LoadLibrary('MyDLL.dll'); //Charge
la DLL
...........................................
FreeLibrary(Hdle); //Libère la
DLL
En ce qui concerne les mots de Flo : il a raison. Une DLL est inutile et en plus n'a pas sa place . Pourquoi ? une DLL doit toujours etre concue dans l'optique meme de sa définition : un ensemble de fonctionnalités génériques pouvant etre intéressentes par un ensemble de programme. Faire une DLL qui n'aura d'intéret que pour un soft, n'a aucune raison d'etre : ce qui est le cas ici (Ton processus de download et de mise à jour ne sera pas utilisable par un autre développeur pour un projet différent). Pire : ca fait flippé l'utilisateur langda, ca encombre le HDD et en terme d'optimisation il y a mieux (sinon on ne ferait que des DLL).
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 20234 11 août 2008 à 18:18
Florenth,
Si tu utilises un bon installateur comme InnoSetup, il supprime les DLL si tu les lui à indiqué comme étant des fichiers à supprimer à la désinstallation.
Francky23012301,
Je suis pas d'accord avec toi.
Mon programme est actuellement composé d'un fichier EXE qui est le programme lui même et d'une DLL étant le format du fichier que j'enregistre.
Si je suis ce que tu dis, je dois tous rassembler en un fichier EXE, hors cela n'est pas l'idéale car celui-ci peut devenir énorme.
Le mieux étant toujours des fichiers de petites tailles, qui seront mis à jour indépendamment des autres, ce qui réduit le temps de téléchargement et permettre donc à ceux qui ont encore une petite connexion (oui il y a encore des 56K malheureusement), de faire rapidement la mise à jour.
Mais bon, je suis votre conseil, je suis entrain de faire un fichier EXE à part pour le système de mise à jour ;)
J'ai pas dis ca Christophe : j'ai seulement dis qu'une DLL est un code binaire contenant des routines génériques. C'est une bibliothèque municipale contenant non pas de livres mais de fonctions : cette bibliotheque est destinée donc un public et non à une seule personne (Pour rester dans la caricature ). Dans ton cas tu as fais une bibliotheque municipale pour une seule personne.
Tu te dois effectivement faire cette procédure dans un EXE. Et pour finir une DLL ne devrait jamais contenir de forms directement .
Ah oui pour finir : Que tu es deux fichiers de 50Mo ou un seul de 100Mo ca ne change pas grand chose (pour pas dire rienà. Ce qui compte c'est de créer et libérer les objets en tant voulus (et pas uniquement à la création et à la fermeture du Main)
, d'avoir un code optimisé, évité les rafraichissements inutiles, utiliser les bonnes technologies ect ect
florenth
Messages postés1023Date d'inscriptiondimanche 1 août 2004StatutMembreDernière intervention17 août 20083 11 août 2008 à 20:45
Euh je conteste un peu tes dires Francky.
Avoir des dll permet de "décentraliser" des fonctions, qui peut être seront communes à d'autres programmes. Cela sert aussi à soulager la RAM car l'exe est chargé entièrement en mémoire en permanence contrairement à la dll qui ne l'est que quand on en a besoin.
De plus, comme le signale Christophe, ça permet de mettre à jour de petits éléments sans avoir recours à un "patcher" à la unix-like. Cela dit, c'est un détail. Les patchers sont très pratiques.
Par contre, je rejoins Francky sur les fiches dans les forms, ça risque de te poser plus de problèmes que ça va en résoudre. Et d'après une pteite enquête menée par Cirec, Forman, quelque'un dont j'ai oublié le nom (pardon^^) et moi, les reactions de l'OS face à ces fiches sont très variées, ce qui signifie que ce qui marche sur ton ordi ne machera pas forcément partout.
Voila, maintenant, si c'est pour une mise à jour, étant donné qu'il te faut un programme annexe (une exe ne peut pas s'auto-modifier), alors il est judicieux de regrouper le code de mise à jour dans cet annexe.
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 20234 11 août 2008 à 21:03
OK, merci pour les informations.
Là je suis donc entrain de faire un EXE séparé qui fait les mises à jour (c'est dur à gérer avec un TClientSocket, ne comprenant pas le TIdHTTP, je verrais pour la version suivante ;)).
J'ai pas dit le contraire Flo ^^ : je parlais de deux executables (.EXE).
Par contre une solution pour la mémoire est d'utiliser le multithread : ca soulage.
Christophe : TClientSocket ne gere pas nativement le protocole HTTP. Va falloir tout coder toi même alors qu'Indy il y a juste a creer ton IdHTTP dynamiquement et balancer un get. Meme si Indy c'est pas le pied, le IdHTTP est suffisant pour ce que tu veux faire.
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 20234 11 août 2008 à 23:35
Oui je sais, mais je trouve pas dans la doc comment m'en servir et c'est tous en anglais (ils n'ont pas traduit cette partie).
Mais bon là j'ai pas de soucis pour le moment ;)
La doc d'Indy est un pavé indigiste (Sont fous ces ricains ).
La seule difficulté est si tu veux récupérer l'état de l'avancement du téléchargement. Mais pour une mise à jour, perso, pour moi ca doit etre invisible : autrement dit pas de barre de progression. Juste une alerte pour dire qu'une nouvelle version est présente et donner le choix d'accepter ou non la mise à jour. Ensuite un petit messagebox pour dire que le download est finit et demander à l'utilisateur s'il veut réaliser la mise à jour maintenant ou plutard. Il y a rien de plus pénible quand tu es entrain de bosser et que tu vois une grosse forme avec une progressbar qui te bouffe tout ton écran : c'est comme 1 femme avec des chaussettes au lit c'est un tue l'amour .
cs_christophedlr
Messages postés267Date d'inscriptionsamedi 3 janvier 2004StatutMembreDernière intervention23 août 20234 12 août 2008 à 09:18
Lol le coup de la progressbar, si la fenêtre n'est pas énorme ça gène pas.
Ce qui gène en revanche c'est que la MAJ se fasse sans qu'on le demande ce qui ne sera pas le cas.
Pour Indy, j'ai fait des tests cette nuit(je suis un couche-tard lol) et j'ai réussi à mon servir, donc je vais te faire plaisir : mon TClientSocket va sauter au profit du TIdHTTP.
Une ProgressBar est utile pour savoir où en est la mise à jour ;)