Bonjour,
dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket
(citizen cbm1000). Je n'utilise pas de pilote windows et j'écris
directement sur le port com, pour des raisons évidentes de rapidité.
Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre
pour activer le massicot ou le tiroir.
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur
plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et
des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar,
le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket,
vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ?
j'ai entendu parler des pilotes Opos. J'ai entendu parler aussi de
"serveurs d'imprimantes ticket" (écrits en assembleur, je crois).
Auriez-vous un retour d'expérience à ce sujet.
PS. Vu la lenteur désespérante des pilotes windows pour ce genre
d'imprimante, je préfèrerais attaquer directement les ports com.
question : comment "attraper" le port com1 d'une autre machine ?
Allez... bon week-end :)
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
"jacques trepp" a écrit dans le message de news:446dca9a$0$8023$
Bonjour, dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket (citizen cbm1000). Je n'utilise pas de pilote windows et j'écris directement sur le port com, pour des raisons évidentes de rapidité. Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre pour activer le massicot ou le tiroir.
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar, le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket, vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ? j'ai entendu parler des pilotes Opos. J'ai entendu parler aussi de "serveurs d'imprimantes ticket" (écrits en assembleur, je crois).
Auriez-vous un retour d'expérience à ce sujet.
PS. Vu la lenteur désespérante des pilotes windows pour ce genre d'imprimante, je préfèrerais attaquer directement les ports com. question : comment "attraper" le port com1 d'une autre machine ?
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer - un fichier de job ton programme principal génére des jobs à imprimer. apres t'ajoute un programme d'impression par imprimante lire le prochain job envoyer le job à un ordi ou à une imprmante (envoi imp= impression sur port com, envoi ordi= transmission par socket par exemple)
sur chaque ordi distant tu ajoute un programme d'écoute: attendre un job pour chaque job recu, ajouter le job à la file locale puis tu ajoute aussi le programme d'impression local: lire le prochain job envoyer le job à une imprmante
ca te fait : 1 programme principal 1 programme d'impression local et de transfert distant 1 programme d'attente de transfert (tu peux éventuellement faire les n°2 et 3 dans le meme programme)
"jacques trepp" <jacques.trepp@free.fr> a écrit dans le message de
news:446dca9a$0$8023$626a54ce@news.free.fr...
Bonjour,
dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket
(citizen cbm1000). Je n'utilise pas de pilote windows et j'écris
directement sur le port com, pour des raisons évidentes de rapidité.
Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre
pour activer le massicot ou le tiroir.
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur
plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et
des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar,
le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket,
vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ?
j'ai entendu parler des pilotes Opos. J'ai entendu parler aussi de
"serveurs d'imprimantes ticket" (écrits en assembleur, je crois).
Auriez-vous un retour d'expérience à ce sujet.
PS. Vu la lenteur désespérante des pilotes windows pour ce genre
d'imprimante, je préfèrerais attaquer directement les ports com.
question : comment "attraper" le port com1 d'une autre machine ?
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer
- un fichier de job
ton programme principal génére des jobs à imprimer.
apres t'ajoute un programme d'impression par imprimante
lire le prochain job
envoyer le job à un ordi ou à une imprmante
(envoi imp= impression sur port com, envoi ordi= transmission par socket par
exemple)
sur chaque ordi distant tu ajoute un programme d'écoute:
attendre un job
pour chaque job recu, ajouter le job à la file locale
puis tu ajoute aussi le programme d'impression local:
lire le prochain job
envoyer le job à une imprmante
ca te fait :
1 programme principal
1 programme d'impression local et de transfert distant
1 programme d'attente de transfert
(tu peux éventuellement faire les n°2 et 3 dans le meme programme)
"jacques trepp" a écrit dans le message de news:446dca9a$0$8023$
Bonjour, dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket (citizen cbm1000). Je n'utilise pas de pilote windows et j'écris directement sur le port com, pour des raisons évidentes de rapidité. Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre pour activer le massicot ou le tiroir.
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar, le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket, vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ? j'ai entendu parler des pilotes Opos. J'ai entendu parler aussi de "serveurs d'imprimantes ticket" (écrits en assembleur, je crois).
Auriez-vous un retour d'expérience à ce sujet.
PS. Vu la lenteur désespérante des pilotes windows pour ce genre d'imprimante, je préfèrerais attaquer directement les ports com. question : comment "attraper" le port com1 d'une autre machine ?
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer - un fichier de job ton programme principal génére des jobs à imprimer. apres t'ajoute un programme d'impression par imprimante lire le prochain job envoyer le job à un ordi ou à une imprmante (envoi imp= impression sur port com, envoi ordi= transmission par socket par exemple)
sur chaque ordi distant tu ajoute un programme d'écoute: attendre un job pour chaque job recu, ajouter le job à la file locale puis tu ajoute aussi le programme d'impression local: lire le prochain job envoyer le job à une imprmante
ca te fait : 1 programme principal 1 programme d'impression local et de transfert distant 1 programme d'attente de transfert (tu peux éventuellement faire les n°2 et 3 dans le meme programme)
jacques trepp
patrice a écrit :
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer - un fichier de job ton programme principal génére des jobs à imprimer. apres t'ajoute un programme d'impression par imprimante lire le prochain job envoyer le job à un ordi ou à une imprmante (envoi imp= impression sur port com, envoi ordi= transmission par socket par exemple)
sur chaque ordi distant tu ajoute un programme d'écoute: attendre un job pour chaque job recu, ajouter le job à la file locale puis tu ajoute aussi le programme d'impression local: lire le prochain job envoyer le job à une imprmante
ca te fait : 1 programme principal 1 programme d'impression local et de transfert distant 1 programme d'attente de transfert (tu peux éventuellement faire les n°2 et 3 dans le meme programme)
Merci. L'idée est intéressante et demande à être creusée. J'enregistre déjà le journal dans un fichier texte au format impression, c_a_d en incluant les séquences esc (police, massicot, etc). un simple TYPE JOBX.TXT > COM1 fonctionne bien.
On avais plus ou moins résolu le problème en installant des pilotes 'générique texte', et donnant les commandes Esc/Pos pour les polices. Le tout sur une imprimante matricielle epson.
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
patrice a écrit :
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer
- un fichier de job
ton programme principal génére des jobs à imprimer.
apres t'ajoute un programme d'impression par imprimante
lire le prochain job
envoyer le job à un ordi ou à une imprmante
(envoi imp= impression sur port com, envoi ordi= transmission par socket par
exemple)
sur chaque ordi distant tu ajoute un programme d'écoute:
attendre un job
pour chaque job recu, ajouter le job à la file locale
puis tu ajoute aussi le programme d'impression local:
lire le prochain job
envoyer le job à une imprmante
ca te fait :
1 programme principal
1 programme d'impression local et de transfert distant
1 programme d'attente de transfert
(tu peux éventuellement faire les n°2 et 3 dans le meme programme)
Merci. L'idée est intéressante et demande à être creusée.
J'enregistre déjà le journal dans un fichier texte au format impression,
c_a_d en incluant les séquences esc (police, massicot, etc).
un simple TYPE JOBX.TXT > COM1 fonctionne bien.
On avais plus ou moins résolu le problème en installant des pilotes
'générique texte', et donnant les commandes Esc/Pos pour les polices. Le
tout sur une imprimante matricielle epson.
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
Moi à ta place je m'inspirerai de la gestion des jobs windows
- un job= 1 ticket à imprimer - un fichier de job ton programme principal génére des jobs à imprimer. apres t'ajoute un programme d'impression par imprimante lire le prochain job envoyer le job à un ordi ou à une imprmante (envoi imp= impression sur port com, envoi ordi= transmission par socket par exemple)
sur chaque ordi distant tu ajoute un programme d'écoute: attendre un job pour chaque job recu, ajouter le job à la file locale puis tu ajoute aussi le programme d'impression local: lire le prochain job envoyer le job à une imprmante
ca te fait : 1 programme principal 1 programme d'impression local et de transfert distant 1 programme d'attente de transfert (tu peux éventuellement faire les n°2 et 3 dans le meme programme)
Merci. L'idée est intéressante et demande à être creusée. J'enregistre déjà le journal dans un fichier texte au format impression, c_a_d en incluant les séquences esc (police, massicot, etc). un simple TYPE JOBX.TXT > COM1 fonctionne bien.
On avais plus ou moins résolu le problème en installant des pilotes 'générique texte', et donnant les commandes Esc/Pos pour les polices. Le tout sur une imprimante matricielle epson.
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Eric
jacques trepp a écrit :
Bonjour,
[cut]
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar, le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket, vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ?
de mon coté, je traite cela en déclarant les imprimantes dans mon prog, pas dans windows, si imprimante reseau, adresse ip de la machine dans le soft,, ping ->ok imprimante ok . impression de la station emettrice vers fichiers asci, transfert en ftp sur la station qui imprime,traitement de la station qui imprime vers l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un soft en tache de fonds qui fait du ftp et qui permet d'imprimer
vla
Allez... bon week-end :)
ce'st parti eric
-- Les Lapys le lapy world howto-contribution-forum pour SME http://leslapys.com
jacques trepp a écrit :
Bonjour,
[cut]
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur
plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et
des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar,
le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket,
vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ?
de mon coté, je traite cela en déclarant les imprimantes dans mon prog,
pas dans windows, si imprimante reseau, adresse ip de la machine dans le
soft,, ping ->ok imprimante ok .
impression de la station emettrice vers fichiers asci, transfert en ftp
sur la station qui imprime,traitement de la station qui imprime vers
l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station
qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un
soft en tache de fonds qui fait du ftp et qui permet d'imprimer
vla
Allez... bon week-end :)
ce'st parti
eric
--
Les Lapys le lapy world
howto-contribution-forum pour SME
http://leslapys.com
La où ça se gâte, c'est quand j'ai besoin d'imprimer une commande sur plusieurs imprimantes (exemple, dans une commande, j'ai des boissons et des sandwitches. Je dois imprimer les boissons sur l'imprimante du bar, le reste sur l'imprimante cuisine).
Sachant que je peux avoir plusieurs ensembles ordi+imprimante ticket, vous conviendrez que ça se complique encore plus.
Comment aborder ce problème ?
de mon coté, je traite cela en déclarant les imprimantes dans mon prog, pas dans windows, si imprimante reseau, adresse ip de la machine dans le soft,, ping ->ok imprimante ok . impression de la station emettrice vers fichiers asci, transfert en ftp sur la station qui imprime,traitement de la station qui imprime vers l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un soft en tache de fonds qui fait du ftp et qui permet d'imprimer
vla
Allez... bon week-end :)
ce'st parti eric
-- Les Lapys le lapy world howto-contribution-forum pour SME http://leslapys.com
jacques trepp
Eric a écrit :
de mon coté, je traite cela en déclarant les imprimantes dans mon prog, pas dans windows, si imprimante reseau, adresse ip de la machine dans le soft,, ping ->ok imprimante ok . impression de la station emettrice vers fichiers asci, transfert en ftp sur la station qui imprime,traitement de la station qui imprime vers l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un soft en tache de fonds qui fait du ftp et qui permet d'imprimer
bonjour, j'envisage de plus en plus cette solution, à une variante près: ne pas utiliser ftp. Je m'explique. la déclaration des imprimantes peut inclure le couple : IP-ordi + N° Port COM dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le serveur de fichiers, chaque poste ayant un programme ou service pour détecter si une impression est en attente pour un poste donné. Je répète que j'écris directement sur les ports com. Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
merci
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Eric a écrit :
de mon coté, je traite cela en déclarant les imprimantes dans mon prog,
pas dans windows, si imprimante reseau, adresse ip de la machine dans le
soft,, ping ->ok imprimante ok .
impression de la station emettrice vers fichiers asci, transfert en ftp
sur la station qui imprime,traitement de la station qui imprime vers
l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station
qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un
soft en tache de fonds qui fait du ftp et qui permet d'imprimer
bonjour,
j'envisage de plus en plus cette solution, à une variante près: ne pas
utiliser ftp. Je m'explique.
la déclaration des imprimantes peut inclure le couple :
IP-ordi + N° Port COM
dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le
serveur de fichiers, chaque poste ayant un programme ou service pour
détecter si une impression est en attente pour un poste donné.
Je répète que j'écris directement sur les ports com.
Comment gérer le spool si mon service me lance une impression pendant
que je lance volontairement une impression ?
merci
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
de mon coté, je traite cela en déclarant les imprimantes dans mon prog, pas dans windows, si imprimante reseau, adresse ip de la machine dans le soft,, ping ->ok imprimante ok . impression de la station emettrice vers fichiers asci, transfert en ftp sur la station qui imprime,traitement de la station qui imprime vers l'imprimante (com1.2.3.4.5.6)
si le ping ne marche pas ->impression du bon de commande sur la station qui emet.
c'est bizar, mais c'est une solution pas excessive.
ca veut dire que chaque station qui serts de serveur d'impression à un soft en tache de fonds qui fait du ftp et qui permet d'imprimer
bonjour, j'envisage de plus en plus cette solution, à une variante près: ne pas utiliser ftp. Je m'explique. la déclaration des imprimantes peut inclure le couple : IP-ordi + N° Port COM dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le serveur de fichiers, chaque poste ayant un programme ou service pour détecter si une impression est en attente pour un poste donné. Je répète que j'écris directement sur les ports com. Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
merci
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Vbig
jacques trepp a écrit :
Bonjour, dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket (citizen cbm1000). Je n'utilise pas de pilote windows et j'écris directement sur le port com, pour des raisons évidentes de rapidité. Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre pour activer le massicot ou le tiroir.
Personnellement, j'utilise toujours les drivers windows. Et pour avoir une impression aussi rapide qu'avec un pilotage via port COM, il suffit d'utiliser les polices imprimantes. (Entre un vieux prg DOS et celui passant par driver windows + police imprimante, le temps d'impression est le meme (le lancement de l'impression est parfois légèrement plus long avec le programme windows, mais il est négligeable)
Ensuite, je n'ai plus de problèmes de sélection d'imprimante partagée ou non, sur le port com ou //, de modèles différents.
Pour certainnes imprimantes, je passe des commandes directement sur le port com pour l'ouverture du tirroir caisse, mais dans la plupart des cas, c'est géré par le driver windows.
jacques trepp a écrit :
Bonjour,
dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket
(citizen cbm1000). Je n'utilise pas de pilote windows et j'écris directement
sur le port com, pour des raisons évidentes de rapidité.
Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre pour
activer le massicot ou le tiroir.
Personnellement, j'utilise toujours les drivers windows.
Et pour avoir une impression aussi rapide qu'avec un pilotage via port
COM, il suffit d'utiliser les polices imprimantes. (Entre un vieux prg
DOS et celui passant par driver windows + police imprimante, le temps
d'impression est le meme (le lancement de l'impression est parfois
légèrement plus long avec le programme windows, mais il est
négligeable)
Ensuite, je n'ai plus de problèmes de sélection d'imprimante partagée
ou non, sur le port com ou //, de modèles différents.
Pour certainnes imprimantes, je passe des commandes directement sur le
port com pour l'ouverture du tirroir caisse, mais dans la plupart des
cas, c'est géré par le driver windows.
Bonjour, dans le cadre d'un logiciel de caisse, j'utilise des imprimantes ticket (citizen cbm1000). Je n'utilise pas de pilote windows et j'écris directement sur le port com, pour des raisons évidentes de rapidité. Cela fonctionne très bien, et il y a peu de commandes à mettre en oeuvre pour activer le massicot ou le tiroir.
Personnellement, j'utilise toujours les drivers windows. Et pour avoir une impression aussi rapide qu'avec un pilotage via port COM, il suffit d'utiliser les polices imprimantes. (Entre un vieux prg DOS et celui passant par driver windows + police imprimante, le temps d'impression est le meme (le lancement de l'impression est parfois légèrement plus long avec le programme windows, mais il est négligeable)
Ensuite, je n'ai plus de problèmes de sélection d'imprimante partagée ou non, sur le port com ou //, de modèles différents.
Pour certainnes imprimantes, je passe des commandes directement sur le port com pour l'ouverture du tirroir caisse, mais dans la plupart des cas, c'est géré par le driver windows.
patrice
"jacques trepp" a écrit dans le message de news:4471695d$0$8013$
Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
Il faut ouvrir le port com avant d'entamer un job: si impossible , quelqu'un d'autre imprime
"jacques trepp" <jacques.trepp@free.fr> a écrit dans le message de
news:4471695d$0$8013$626a54ce@news.free.fr...
Comment gérer le spool si mon service me lance une impression pendant
que je lance volontairement une impression ?
Il faut ouvrir le port com avant d'entamer un job: si impossible , quelqu'un
d'autre imprime
"jacques trepp" a écrit dans le message de news:4471695d$0$8013$
Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
Il faut ouvrir le port com avant d'entamer un job: si impossible , quelqu'un d'autre imprime
Exact. Merci
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Eric
jacques trepp a écrit :
Eric a écrit :
bonjour, j'envisage de plus en plus cette solution, à une variante près: ne pas utiliser ftp. Je m'explique. la déclaration des imprimantes peut inclure le couple : IP-ordi + N° Port COM dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le serveur de fichiers, chaque poste ayant un programme ou service pour détecter si une impression est en attente pour un poste donné.
ca c'est biens,
Je répète que j'écris directement sur les ports com. Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
par lancer volontairement une impression tu entends quoi , un autre soft que le tiens ? si c'est en faisant de l'impression on locale ( on parle ticket vers com1 local par ex ) , passe obligatoirement par le serveur d'impression. ca ne change rien on peut trés bien ouvrir un socket en emission avec la même adresse que le socket serveur.
j'avais vu cela dans la lst53
sinon je ne déclare jamais les imprimante série dans windows,
merci
de rien eric
-- Les Lapys le lapy world howto-contribution-forum pour SME http://leslapys.com
jacques trepp a écrit :
Eric a écrit :
bonjour,
j'envisage de plus en plus cette solution, à une variante près: ne pas
utiliser ftp. Je m'explique.
la déclaration des imprimantes peut inclure le couple :
IP-ordi + N° Port COM
dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le
serveur de fichiers, chaque poste ayant un programme ou service pour
détecter si une impression est en attente pour un poste donné.
ca c'est biens,
Je répète que j'écris directement sur les ports com.
Comment gérer le spool si mon service me lance une impression pendant
que je lance volontairement une impression ?
par lancer volontairement une impression tu entends quoi , un autre soft
que le tiens ?
si c'est en faisant de l'impression on locale ( on parle ticket vers
com1 local par ex ) , passe obligatoirement par le serveur d'impression.
ca ne change rien on peut trés bien ouvrir un socket en emission avec la
même adresse que le socket serveur.
j'avais vu cela dans la lst53
sinon je ne déclare jamais les imprimante série dans windows,
merci
de rien
eric
--
Les Lapys le lapy world
howto-contribution-forum pour SME
http://leslapys.com
bonjour, j'envisage de plus en plus cette solution, à une variante près: ne pas utiliser ftp. Je m'explique. la déclaration des imprimantes peut inclure le couple : IP-ordi + N° Port COM dans ce cas, il me suffit d'enregistrer mon fichier d'impression sur le serveur de fichiers, chaque poste ayant un programme ou service pour détecter si une impression est en attente pour un poste donné.
ca c'est biens,
Je répète que j'écris directement sur les ports com. Comment gérer le spool si mon service me lance une impression pendant que je lance volontairement une impression ?
par lancer volontairement une impression tu entends quoi , un autre soft que le tiens ? si c'est en faisant de l'impression on locale ( on parle ticket vers com1 local par ex ) , passe obligatoirement par le serveur d'impression. ca ne change rien on peut trés bien ouvrir un socket en emission avec la même adresse que le socket serveur.
j'avais vu cela dans la lst53
sinon je ne déclare jamais les imprimante série dans windows,
merci
de rien eric
-- Les Lapys le lapy world howto-contribution-forum pour SME http://leslapys.com
jacques trepp
Vbig a écrit :
Personnellement, j'utilise toujours les drivers windows. Et pour avoir une impression aussi rapide qu'avec un pilotage via port COM, il suffit d'utiliser les polices imprimantes.
On parle bien de la même imprimante Citizen CBM 1000 II partial Cut ? Parce que je viens d'installer le pilote windows. Je n'ai vu nulle part d'option concernant les polices de l'imprimante. De plus, l'impression de la page de test a pris plus d'une minute :(
Nom du pilote : RASDD.DLL Fichier de données : CBM1000.DLL Fichier de configuration : RASDDUI.DLL Fichier d'aide RASDDUI.HLP Version de pilote : 3.01
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Vbig a écrit :
Personnellement, j'utilise toujours les drivers windows.
Et pour avoir une impression aussi rapide qu'avec un pilotage via port
COM, il suffit d'utiliser les polices imprimantes.
On parle bien de la même imprimante Citizen CBM 1000 II partial Cut ?
Parce que je viens d'installer le pilote windows.
Je n'ai vu nulle part d'option concernant les polices de l'imprimante.
De plus, l'impression de la page de test a pris plus d'une minute :(
Nom du pilote : RASDD.DLL
Fichier de données : CBM1000.DLL
Fichier de configuration : RASDDUI.DLL
Fichier d'aide RASDDUI.HLP
Version de pilote : 3.01
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
Personnellement, j'utilise toujours les drivers windows. Et pour avoir une impression aussi rapide qu'avec un pilotage via port COM, il suffit d'utiliser les polices imprimantes.
On parle bien de la même imprimante Citizen CBM 1000 II partial Cut ? Parce que je viens d'installer le pilote windows. Je n'ai vu nulle part d'option concernant les polices de l'imprimante. De plus, l'impression de la page de test a pris plus d'une minute :(
Nom du pilote : RASDD.DLL Fichier de données : CBM1000.DLL Fichier de configuration : RASDDUI.DLL Fichier d'aide RASDDUI.HLP Version de pilote : 3.01
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
jacques trepp
Eric a écrit :
par lancer volontairement une impression tu entends quoi , un autre soft que le tiens ?
Non. En fait, je peux de mon ordi imprimer un ticket, pendant que mon service a détecté une impression à effectuer, et est en cours. Mais dans ce cas, je ne devrais pas pouvoir ouvrir le port com. Je n'ai jamais utilisé les threads. ça pourrait m'aider ?
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Eric a écrit :
par lancer volontairement une impression tu entends quoi , un autre soft
que le tiens ?
Non. En fait, je peux de mon ordi imprimer un ticket, pendant que mon
service a détecté une impression à effectuer, et est en cours.
Mais dans ce cas, je ne devrais pas pouvoir ouvrir le port com.
Je n'ai jamais utilisé les threads. ça pourrait m'aider ?
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
par lancer volontairement une impression tu entends quoi , un autre soft que le tiens ?
Non. En fait, je peux de mon ordi imprimer un ticket, pendant que mon service a détecté une impression à effectuer, et est en cours. Mais dans ce cas, je ne devrais pas pouvoir ouvrir le port com. Je n'ai jamais utilisé les threads. ça pourrait m'aider ?
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
