Version imprimable
ok. Je vois bien le problème! Si tu lances un programme utilisant ZLPortIO, il va obtenir les droits pour accèder au port x. Si tu lances un second programme, il ne pourra obtenir l'accès au port puisque celui-ci est comme locké par le 1er programme... C'est pour ça qu'il vaut mieux tout faire dans un seul programme ou centraliser l'accès aux ports...
Que veux-tu faire exactement? :? Explique et détaille bien ton projet stp.
en fait j'ai un programme qui pilote une machine via le port // d'ou l'emploie de ZlportIO.
Ce programme utilise le port // et un certain nombre de dll , qui elles memes utilisent le port // , en fait un syteme de pluging ( maison ) qui sont des dlls quasi autonomes que mon programme va chercher en fonction des besoins de la machines . Donc chaque fois que j'ai besoin d'une dll , je l'iniatialise et lance le driver .
donc ma procedure de chargement est la suivant
1° lancement du prgramme principal -> iniatialisation de Zlportio
2° chargement en dynamique des la Dll 1 -> iniatialisation de Zlportio
3° chargement en dynamique des la Dll 2 -> iniatialisation de Zlportio
... ainsi de suite
en en cours de programme je peux aussi
chargement en dynamique des la Dll 28 -> iniatialisation de Zlportio
voila pour mon projet !
Mon probleme
quand je fais comme tu me disais ( je fesais cela dans l'initialisation de de mon programme principal et aussi toute mes DLL ) :
...
zliostop;
zliostart;
zliosetiopm(True);
..
je ne fonctionne pas du tout !!
par contre si je le fais pas , mais laisse faire seulement l'inialisation de Zlportio çà marche bcp mieux mais de temps il me dis que le drivers est pas charger quand j'inialise mes DLLs.
Pour le savoir je teste la variable 'ZLIOStarted' et j'affiche simplement un showmessage .
Dans mes recherches je me suis rendu compte que c'est la creation du handel qui echoue .
Peut etre que si je savais detruire le handel , je pourrais le fermer et le reouvrir a chaque fois !! mais meme çà je sais pas comment etre sur qu'il a bien ete Hoté !! je pense pas que zliostop le face j'ai essayer et pas bcp de resultat .
J'ai aussi essayé en modifiant le Zlportio pour plus qu'il fasse son inialisation ' tout seul' , de la passer en procedure que je lance depuis un programme et j'essaye d'utiliser le // avec un autre programme en supposant qu'il trouverai tous seul que le drivers est installé , mais non çà marche !!
Avec le programme qui me sert a lancer le drivers (avec la procedure iniatilisation du zlportio ) , parfois il ne charge pas le drivers du 1er coup , par contre une fois chargé une fois , je ne peux plus le recharger tant que je n'ai pas fermer le programme, pourtant je pensais que sur un echec de creation il fermait le Zlportio( finalisation l'unité) et recommencer a le charger.
voila j'ai essayé de te donner toutes mes infos sur mes recherche et merci pour ton temps si tu as une idee elle sera la bien venu car je patoge un peu là !!
Oui, je vois bien que tu patoges en effet! Comme je te l'ai dis, sur un système multi-taches comme WinXp, lorsque tu charges le pilote pour accéder au port, celui-ci "lock" l'accès au port jusqu'au déchargement du pilote. Ainsi, seul un programme (un seul handle) dispose du droit d'accès. Ce que je ferais à ta place, c'est d'initialiser ZlportIO qu'une seule fois, au démarrage du programme et d'intégrer les fonctions de lecture et d'écriture du port parrallèle dans le programme principal et non aux différentes DLL.
Utilise par exemple un système de message Windows pour communiquer entre tes DLLs et le programme principal. SendMessage (ou PostMessage) et PeekMessage (ou GetMessage) te serviront à écrire (envoyer) et lire (recevoir) sur le port à partir de n'importe quelle DLLs... Cela signifie que tu devras fournir aux DLLs, l'handle du programme principale. Cet handle ressemble à une adresse permettant de définir le destinataire (ou l'expéditeur) du message...
http://alphomega.developpez.com/EchangeVal/
http://www.developpez.net/forums/viewtopic.php?t=162466
Je te prépare un exemple... ;)
L'exemple est composé de 2 programmes:
- Init_ZL.exe permet d'initialiser le pilote d'accès direct aux ports (prog principal)
- Test.exe est une démo pour utiliser le port $378h via Init_ZL.exe.
:arrow: http://sub0.developpez.com/delphi/Mess_ZL.zip
Initialisation:
1) Extrait les fichiers dans leur répertoire sur ton disque dur
2) Lance Init_ZL.exe et copie son handle qui est affiché dans l'edit.
3) Lance Test.exe et colle dans l'edit du haut, le handle de Init_ZL.
Les programmes peuvent maintenant communiquer...
Lire et écrire:
4) Entre une valeur allant de 0 à 255 dans le 2ème edit de Test.exe
5) Envoi cette valeur à Init_ZL en cliquant sur WRITE. Cette valeur est alors écrite sur le port $378h par Init_ZL lorsqu'il reçoit le message de Test.exe. Un beep est émi pour confirmer la reception du message par Init_ZL.
6) Clique sur READ pour lire le port. Tu dois normalement retrouver la valeur que tu as entré si rien n'est branché sur le port. Là aussi, un beep est émi pour confirmer la reception du message par Init_ZL.
• Comme tu peux le remarquer, Test.exe a besoin de connaître l'handle du programme principal Init_ZL pour pouvoir lui envoyer des messages. Pour la reception, l'handle du programme Test.exe est inclu dans le paramètre lparam du message, un peu comme les mails finalement, où l'adresse de réponse se trouve dans le message. Tu devras donc t'occuper de distribuer à tes DLLs l'handle du programme principal... Je pense que tu trouveras sûrement une solution simple pour fournir cet handle à tes DLLs...
• Avec ce système, tu peux lancer autant de Test.exe que tu veux, c'est-à-dire accéder aux ports avec différents programmes, en évitant si possible l'accès simultanné sur un même message (risque de conflits). Seul Init_ZL accède véritablement aux ports. Les autres programmes ne font que de lui demander de lire ou d'écrire à leur place. Tu peux définir l'adresse de base du port dans Test.exe, ce qui permet d'écrire et de lire n'importe quel port du pc! Tu peux aussi définir d'autres messages, etc... J'espère que tu as compris le principe. Je voudrais dire aussi, qu'il faudra adapter le système si tu comptes faire de l'accès rapide haute fréquence... N'hésite pas à poser des questions si tu doutes.
à+
j'ai bien vérifier en ZLport mai jai rien vu qui peut donner l'impression qu'il bloc un port présit car la tu crée un service pour communique avec un port quelquenque pouvu que son adresse etre de 0 à 255(et je pence mem jusqua 65322-2^16)Citation:
Oui, je vois bien que tu patoges en effet! Comme je te l'ai dis, sur un système multi-taches comme WinXp, lorsque tu charges le pilote pour accéder au port, celui-ci "lock" l'accès au port jusqu'au déchargement du pilote. Ainsi, seul un programme (un seul handle) dispose du droit d'accès. Ce que je ferais à ta place, c'est d'initialiser ZlportIO qu'une seule fois, au démarrage du programme et d'intégrer les fonctions de lecture et d'écriture du port parrallèle dans le programme principal et non aux différentes DLL.
alors si cest vrai en peut crée un autre service par un notre nom si le prog point seulement dans l'apel du précednet :?:
J'ai pas compris ce que tu veux dire...
Il suffit de lancer mes 2 démos (LPT_1 et LPT_1b) en simultanné pour se rendre compte que ça bloque... L'une scanne les entrées, l'autre les sorties. Les deux fonctionnent si on n'en lance qu'une sur les 2. Si on lance ces 2 appli ensemble, le pilote ZLPortIO est bloqué. C'est pas le port qui est bloqué, mais le pilote...Citation:
j'ai bien vérifier en ZLport mai jai rien vu qui peut donner l'impression qu'il bloc un port présit...
Effectivement, on peut comparer ce système à un service. On peut l'utiliser pour accéder à n'importe quel port du pc...Citation:
...car la tu crée un service pour communique avec un port quelquenque pouvu que son adresse etre de 0 à 255(et je pence mem jusqua 65322-2^16)
On utilise qu'une seule instance de ZLPortIO pour permettre à plusieurs programmes d'accéder aux ports. Cela évite de lancer plusieurs fois le pilote et de se retrouver bloqué...
Pardon?Citation:
alors si cest vrai en peut crée un autre service par un notre nom si le prog point seulement dans l'apel du précednet :?:
Non. C'est le fait de lancer plusieurs fois le pilote ZLPortIO qui pose problème. Si on lance plusieurs services, on se retrouve bloqué, au même point qu'au départ...
sub: le zlportio.sys comment est il crée??
Le fichier ZLPORTIO.SYS est ici l'équivalent d'un EXE (programme compilé) sauf qu'il possède une extension SYS.Citation:
Envoyé par edam
Lorsqu'on charge ZLPORTIO.SYS, celui-ci est éxécuté comme un programme résident, un service...
Quel est le but de cette question au juste? ok, je vois où tu veux en venir...
Si tu penses utiliser ce service avec plusieurs EXE, pourquoi pas... C'est pas bête!
Mais vu le code de l'unité, c'est plus chaud à programmer je crois (faudra être sûr de son code).
En fait, cela revient à mémoriser l'handle du pilote initialisé qu'une seule fois pour l'utiliser dans plusieurs programmes.
non c'est pas sa meme j'aime bien que tu dévellope un peu votre réponce car c'est une bonne idéeCitation:
Quel est le but de cette question au juste? ok, je vois où tu veux en venir...
Si tu penses utiliser ce service avec plusieurs EXE, pourquoi pas... C'est pas bête!
Mais vu le code de l'unité, c'est plus chaud à programmer je crois (faudra être sûr de son code).
mon idée est de crée un service pour chaque projet bien sur il faut la differencier les nom
au début de l'unite zlportio:
j'ai pencer qu'on modifient ZLIODriverName on peut crée un autre service c'est sa mon idéeCode:
2
3
4
5
je sais si cest juste car jai jamai crée un seul service mais je pence que je vais commencer dés maintenant
J'ai trouvé! ;)
Dans l'unité ZLPortIO, on peut trouver Initialization et finalization...
Il faut transformer ces 2 procédures pour pouvoir les appeller non pas directement dans l'unité, mais à partir du programme principal. En effet, à chaque fois que vous ajouter ZLPortIO dans la clause USES, le code d'initialisation est éxécuté... Et comme il génère un nouvel handle à chaque fois...
Je prépare le nouveau code et une démo, à+
Sub0 , ta derniere manip avec l'inialisation , et la finalisation passé en procedure , je l'avais deja faite ( surement que je me suis mal expliqué , quand j'ai fais un resumé de mes manip et tu l'a pas comprise ) et çà marchais pas !!
mais je passais pas le nom du handle au DLL !! :oops: des fois le repos remet aussi les idées en place :lol:
donc je vais essayer et vous tenir au courant!!
Un truc bizarre j'ai cru voir le post ou Sub0 avait modifié le zlportio avec les initialisation et finalination en procedure , mais il semble avoir disparu!!?? :roll:
Justement non!!Citation:
Envoyé par edam
Il ne peut y avoir qu'un seul service qui accède au port...
Enfin selon moi.
Je vais tout de même faire des essais.
En effet, je l'ai supprimé car ce ne fonctionnait pas vraiment. Il fallait faire des modifs suplémentaires...Citation:
Envoyé par petitcoucou31
Selon moi, il faut lancer le service dans le programme principal...
Les autres programmes devront utiliser ce même service sans l'interromprent. Il faut donc mémoriser le handle quelque part ou l'obtenir par un moyen ou un autre. Perso, je n'ai jamais trop programmé ce genre d'appli, c'est pour cette raison que le système avec les messages windows me semblait pas mal, il a le mérite d'être simple au moins! ;)
Mais bon, je reconnais que c'est pas top.
Bon finalement, ton idée a l'air de fonctionner! :bravo:Citation:
Envoyé par Sub0
J'ai changé le nom du fichier SYS et le nom du pilote dans l'unité...
Ce que l'on peut faire maintenant, c'est un système qui crée un nom aléatoire.
- Création du fichier système avec le nom aléatoire
- Définir le nom du pilote avec ce même nom
Cela permettra aussi d'intégrer le fichier SYS à l'appli...
Qu'en pensez-vous?
merci sub de votre attention
la vériter jai pas actuellement de poste pour faire les teste et tt, tt ce que jai fai cest d'imprimer les 2 uniter zlportio et l'autre jai oublier son non
cest normalle qu'on a des service qui accéde au port en meme temp:webcam,clavier ,souri,......
jai jamai utliser les service alors si tu as un peut de temp pour l'expliquer et tt. alors merci vraiment surtout si vs pouvez l'ajouter dans la faq delphi sa sera genial
jai pas vraiment compris ce que tu as suprimer ce qui doit etre changer et les modif aporte :oops: :oops:Citation:
En effet, je l'ai supprimé car ce ne fonctionnait pas vraiment. Il fallait faire des modifs suplémentaires
je pence que jai pas trop demander mai je veu bien comprendre le max alors soyey passion avec moi ok :idea: :idea: :?:
Je crois avoir trouvé la solution...
:arrow: http://sub0.developpez.com/delphi/LPT_1d.zip
Je nome le service avec le handle du programme principal tout simplement. Le fichier SYS conserve son nom... Pour tester cette démo, extraire les fichiers, et lancer plusieurs fois l'appli. Lorsqu'on modifie la valeur du port dans un programme, elle est répercutée dans les autres. Cela signifie bien que l'on écrit sur le port. Vérifier bien que vous pouvez ouvrir et fermer plusieurs programmes à volonté dans n'importe quel ordre. A tester!
Edam, tu trouveras dans ces sources, les unités modifiées... Dans le code original, l'initialisation et la finalisation du pilote étaient automatiques. Dans ces sources, on initialise le pilote avec ZLInit, et on le termine avec ZLFinalize. Ces 2 fonctions intègrent zliostart et zliostop. Au fait, merci Edam de nous avoir mis sur la voix! ;)
Maintenant, il faudrait voir si ce système fonctionne avec des DLLs... J'utilise Application.handle pour récupérer le handle de l'application et m'en servir pour nommer le service (en paramètre de ZLInit). Je ne sais pas si cela est géré aussi par les DLLs. Sinon, il faudra remplacer application.handle par autre chose afin de donner au service un nom unique. Peut-être le nom de la DLL par exemple... car application.handle risque peut-être d'être le même pour toutes les DLLs. petitcoucou31, à toi maintenant de tester et de voir si ça te convient. Tiens-nous informés!
Une dernière chose, il faudra appeller un ZLInit et un ZLFinalize pour chacune des DLL finalement, puisqu'il ya un service pour chaque DLL. Le fait d'avoir transformé l'initialisation et la finalisation en procédures n'était pas vraiment nécessaire en fin de compte... Mais bon, perso je préfère ainsi.
à+
merci sub je vai imprimer tt sa et le voir puis je prépare d'autre question
merci encore
:)
Salut a tout les deux !
voila le resutat des modifs que j'ai apporté a mon code. J'ai dont utilisé l'unité ZLportio , avec les modifs de l'initialisation et finalisation qui ne semble neccesaire , mais je prefere aussi le faire par moi meme !
je decris si dessous la demarche dans laquelle se deroule les initialisations peut etre plus simple que de tout expliqué.( a savoir toutes mes dll ont une fonction d'initialisation qui est lancé au debut de mon application)
1° lancement de mon application
2° dans le Formcreate de mon application ,ZLInit(avec application.handle )
3° dans le Formcreate de mon application ,chargement dynamique de toutes mes dlls
4° dans le Formcreate de mon application ,initialisation de mes Dlls (et dans chaque initialisation de toute mes dll) ZLInit( avec application.handle )
...
5° utilisation de mon programme et de mes DLL avec le port //
....
....
4° fermeture de mon programme (qui fait la ZLfinalisation dans le FormDestroy)
Je teste toujour le ZlIOStarted apres le ZLInit pour etre sur que le drivers est bien charger apres chaque appel de ZLInit, jusqu'a present j'ai pas eus de defaut.
donc voila mes remarques :
j'ai fait les plusieurs manips de charger ZLInit avec comme parametre soit le application.handle , soit les nom des DLLs , soit avec une valeur fixe ( handle= 1) et çà marche dans tout les cas !
remarque: le "application.handle" dans une DLL et toujours egal a "0"
Donc si j'ai bien compris , je crée plusieurs fois un meme service ( avec un meme handle ! et cela a chaque initialisation de Zlportio !! et çà marche quand meme !! ( alors que çà devrai pas si j'ai bien compris )
comme on le voit l'initialise le port // de mes dlls une seule fois au debut
donc je ne fais jamais de finalisation pour les drivers ouvert par les dll et seulement un seul a la fin de mon programme principal
voila mes conclusions !
SUB0 si tu me dit comment t'envoyer un programme je peux inclure une DLL a ton source pour te l'envoyer si tu veux jeter un coup d'oeil !
Donc je me demande si c'est simplement pas la finalisation qui pose probleme , quand on charge plusieurs le drivers et pas le handle !!
a bientot
Oui, c'est ce que j'ai remarqué! Si tu utilises le même nom de service pour toutes les DLLs, cela ne posera pas de problème tant que tu ne finaliseras pas l'une d'entre-elles, auquel cas, le prochain service crée ne fonctionnera pas (accès au port sans effets)... Enfin, c'est ce que j'ai pu analysé des tests effectués. Maintenant, si tu initialises et finalises toutes tes DLLs en même temps, tu peux alors utiliser le même nom pour leur service. Mais bon, perso je te conseil d'utiliser un nom différent pour chaque service, par exemple le nom de la DLL, juste à le passer en paramètre de la fonction ZLInit et comme ça tu seras tranquille.Citation:
et çà marche quand meme
Non, ce n'est pas nécessaire puisque ça fonctionne... Le problème est résolu! ;)Citation:
SUB0 si tu me dit comment t'envoyer un programme je peux inclure une DLL a ton source pour te l'envoyer si tu veux jeter un coup d'oeil !
Exactement, c'est ce que j'ai conclu moi aussi.Citation:
Donc je me demande si c'est simplement pas la finalisation qui pose probleme , quand on charge plusieurs le drivers et pas le handle !!
Evidemment, l'idéal aurait été d'initialiser le service qu'une seule fois, et utiliser le même pour toutes les DLLs, cependant je ne sais pas comment il faut procéder pour obtenir ce système... Mais bon, on ne va pas chipoter, l'essentiel est que ton programme fonctionne! Et puis, c'est mieux finalement, puisqu'on peut maintenant lancer plusieurs programmes utilisant ZLPortIO sans que les services rentrent en conflit... Peut-être serait-il intérressant d'en parler à l'auteur pour connaître son avis sur la question. On lui envoit un mail? :D
à+