Dans mon application médicale, j'ai de nombreuses possibilités
d'impressions.
Comme cela concerne parfois un nombre important de patients, je
voudrais que l'utilisateur de l'application soit débarrassé le plus
vite possible de la pahse d'impressions qui peut prendre du temps.
Plusieurs possibilités s'offrent à moi:
1) Utiliser un serveur d'impression (bon exemple dans la dernière LST.
L'astuce est que le serveur est "loin" et que les imprimantes
concernées sont sur plusieurs sites mais c'est à retenir..
2) Utiliser des thread en combinant la complilation dynamique. En
clair, je complile le code servant à imprimer. La procédure résulant de
cette compilation est exécutée dans un thread. Le nom ce cette
procédure change (="P"+datesys+heuresys) de manière à permettre à
l'utilisateur d'utilser la même procédure alors que la première n'est
pas terminée
Avez-vous d'autres idées ?
Merci
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
patrice
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
2) Utiliser des thread en combinant la complilation dynamique. En clair, je complile le code servant à imprimer. La procédure résulant de cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la compilation dynamique du coup le thread peut s'arreter à tout moment avec la fenetre de traitement d'exception. a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la fonction suivante.
procedure test() quand exception dans d est une date d..jour=0 renvoyer "" faire renvoyer exceptioninfo() exceptionactive() fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le meme qui l'original), qui scan un fichier et exécute les traitements d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en tant que service.
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.5d017d7442d08c13.28828@skynet.be...
2) Utiliser des thread en combinant la complilation dynamique. En
clair, je complile le code servant à imprimer. La procédure résulant de
cette compilation est exécutée dans un thread. Le nom ce cette
procédure change (="P"+datesys+heuresys) de manière à permettre à
l'utilisateur d'utilser la même procédure alors que la première n'est
pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la
compilation dynamique
du coup le thread peut s'arreter à tout moment avec la fenetre de traitement
d'exception.
a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la
fonction suivante.
procedure test()
quand exception dans
d est une date
d..jour=0
renvoyer ""
faire
renvoyer exceptioninfo()
exceptionactive()
fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le
meme qui l'original), qui scan un fichier et exécute les traitements
d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en
tant que service.
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
2) Utiliser des thread en combinant la complilation dynamique. En clair, je complile le code servant à imprimer. La procédure résulant de cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la compilation dynamique du coup le thread peut s'arreter à tout moment avec la fenetre de traitement d'exception. a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la fonction suivante.
procedure test() quand exception dans d est une date d..jour=0 renvoyer "" faire renvoyer exceptioninfo() exceptionactive() fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le meme qui l'original), qui scan un fichier et exécute les traitements d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en tant que service.
patrice
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tu te galere pour rien. active la gestion à la mimine des sections critiques prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement : - l'acces concurrent au variable globale en écriture/lecture (un thread écrit, un autre lit, cela peut être génant si la lecture est partielle) - l'acces concurrent aux enregistrements du fichier si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des lock) mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un thread par imprimante (a quoi sert d'avoir 10 générations simultanées d'états, si un seul à la fois peut être imprimer)
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.5d017d7442d08c13.28828@skynet.be...
cette compilation est exécutée dans un thread. Le nom ce cette
procédure change (="P"+datesys+heuresys) de manière à permettre à
l'utilisateur d'utilser la même procédure alors que la première n'est
pas terminée
tu te galere pour rien.
active la gestion à la mimine des sections critiques
prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement :
- l'acces concurrent au variable globale en écriture/lecture
(un thread écrit, un autre lit, cela peut être génant si la lecture est
partielle)
- l'acces concurrent aux enregistrements du fichier
si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des
lock)
mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un
thread par imprimante (a quoi sert d'avoir 10 générations simultanées
d'états, si un seul à la fois peut être imprimer)
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tu te galere pour rien. active la gestion à la mimine des sections critiques prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement : - l'acces concurrent au variable globale en écriture/lecture (un thread écrit, un autre lit, cela peut être génant si la lecture est partielle) - l'acces concurrent aux enregistrements du fichier si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des lock) mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un thread par imprimante (a quoi sert d'avoir 10 générations simultanées d'états, si un seul à la fois peut être imprimer)
J-M des Grottes
Dans son message précédent, patrice a écrit :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
2) Utiliser des thread en combinant la complilation dynamique. En clair, je complile le code servant à imprimer. La procédure résulant de cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la compilation dynamique du coup le thread peut s'arreter à tout moment avec la fenetre de traitement d'exception. a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la fonction suivante.
procedure test() quand exception dans d est une date d..jour=0 renvoyer "" faire renvoyer exceptioninfo() exceptionactive() fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le meme qui l'original), qui scan un fichier et exécute les traitements d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en tant que service.
Cela marche très bien et les exceptions semblent gérées, en tous les cas je reçois l'info de l'exception ...)
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
Comme quoi chacun a ses idées et ses recettes
A+
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
Dans son message précédent, patrice a écrit :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.5d017d7442d08c13.28828@skynet.be...
2) Utiliser des thread en combinant la complilation dynamique. En
clair, je complile le code servant à imprimer. La procédure résulant de
cette compilation est exécutée dans un thread. Le nom ce cette
procédure change (="P"+datesys+heuresys) de manière à permettre à
l'utilisateur d'utilser la même procédure alors que la première n'est
pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la
compilation dynamique
du coup le thread peut s'arreter à tout moment avec la fenetre de traitement
d'exception.
a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la
fonction suivante.
procedure test()
quand exception dans
d est une date
d..jour=0
renvoyer ""
faire
renvoyer exceptioninfo()
exceptionactive()
fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le
meme qui l'original), qui scan un fichier et exécute les traitements
d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en
tant que service.
Cela marche très bien et les exceptions semblent gérées, en tous les
cas je reçois l'info de l'exception ...)
Par ailleurs, ton executable scanne un fichier qui contient quoi ?
Le code d'impression ?(cela revient au même puisqu'il faut le
compiler), Le nom de l'état ? (OK, mais alors comment connaître les
paramètres éventuels à injecter dans l'état ou sa requête)...
Comme quoi chacun a ses idées et ses recettes
A+
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
2) Utiliser des thread en combinant la complilation dynamique. En clair, je complile le code servant à imprimer. La procédure résulant de cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tres tres mauvaise idée en wd10: les exceptions ne sont pas gérés par la compilation dynamique du coup le thread peut s'arreter à tout moment avec la fenetre de traitement d'exception. a essayer en wd11 avant de se lancer. essayer d'appeler dynamiquement la fonction suivante.
procedure test() quand exception dans d est une date d..jour=0 renvoyer "" faire renvoyer exceptioninfo() exceptionactive() fin
du coup, la solution que j'utilise est un exécutable bis (qui peut etre le meme qui l'original), qui scan un fichier et exécute les traitements d'impression qui sont dedans. et apres il suffit de mettre cet exécutable en tant que service.
Cela marche très bien et les exceptions semblent gérées, en tous les cas je reçois l'info de l'exception ...)
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
Comme quoi chacun a ses idées et ses recettes
A+
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
patrice
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état. et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé à l'état à imprimer
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.6b387d748c90a49c.28828@skynet.be...
Par ailleurs, ton executable scanne un fichier qui contient quoi ?
Le code d'impression ?(cela revient au même puisqu'il faut le
compiler), Le nom de l'état ? (OK, mais alors comment connaître les
paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état.
et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé
à l'état à imprimer
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état. et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé à l'état à imprimer
J-M des Grottes
patrice avait prétendu :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état. et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé à l'état à imprimer
Merci Msieur et bon dev
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
patrice avait prétendu :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.6b387d748c90a49c.28828@skynet.be...
Par ailleurs, ton executable scanne un fichier qui contient quoi ?
Le code d'impression ?(cela revient au même puisqu'il faut le
compiler), Le nom de l'état ? (OK, mais alors comment connaître les
paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état.
et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé
à l'état à imprimer
Merci Msieur et bon dev
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
Par ailleurs, ton executable scanne un fichier qui contient quoi ? Le code d'impression ?(cela revient au même puisqu'il faut le compiler), Le nom de l'état ? (OK, mais alors comment connaître les paramètres éventuels à injecter dans l'état ou sa requête)...
ca contient bien sur le nom de l'état. et pour les paramètres de l'état j'ai un fichier de type Nom/Valeur associé à l'état à imprimer
Merci Msieur et bon dev
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
J-M des Grottes
patrice avait énoncé :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tu te galere pour rien. active la gestion à la mimine des sections critiques prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement : - l'acces concurrent au variable globale en écriture/lecture (un thread écrit, un autre lit, cela peut être génant si la lecture est partielle) - l'acces concurrent aux enregistrements du fichier si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des lock) mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un thread par imprimante (a quoi sert d'avoir 10 générations simultanées d'états, si un seul à la fois peut être imprimer)
En mettant un sémaphore dans mes chaines à compiler, les thread d'impression sont envoyés les uns derrière les autres et ne bloquent pas l'utilisateur Merci
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
patrice avait énoncé :
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message
de news:mn.5d017d7442d08c13.28828@skynet.be...
cette compilation est exécutée dans un thread. Le nom ce cette
procédure change (="P"+datesys+heuresys) de manière à permettre à
l'utilisateur d'utilser la même procédure alors que la première n'est
pas terminée
tu te galere pour rien.
active la gestion à la mimine des sections critiques
prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement :
- l'acces concurrent au variable globale en écriture/lecture
(un thread écrit, un autre lit, cela peut être génant si la lecture est
partielle)
- l'acces concurrent aux enregistrements du fichier
si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des
lock)
mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un
thread par imprimante (a quoi sert d'avoir 10 générations simultanées
d'états, si un seul à la fois peut être imprimer)
En mettant un sémaphore dans mes chaines à compiler, les thread
d'impression sont envoyés les uns derrière les autres et ne bloquent
pas l'utilisateur
Merci
--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique
"J-M des Grottes" <j-mdesgrottes(nospam)@skynet.be> a écrit dans le message de news:
cette compilation est exécutée dans un thread. Le nom ce cette procédure change (="P"+datesys+heuresys) de manière à permettre à l'utilisateur d'utilser la même procédure alors que la première n'est pas terminée
tu te galere pour rien. active la gestion à la mimine des sections critiques prend un context hyperfile indépendant pour chaque thread.
du coup, la seule chose qui tu doit gérer en section critique expliciement : - l'acces concurrent au variable globale en écriture/lecture (un thread écrit, un autre lit, cela peut être génant si la lecture est partielle) - l'acces concurrent aux enregistrements du fichier si plusieurs thread lise une fiche instruction pour l'éxécuté (prévoi des lock) mais attention, dans ton cas, je pense que tu ne peux avoir au plus qu'un thread par imprimante (a quoi sert d'avoir 10 générations simultanées d'états, si un seul à la fois peut être imprimer)
En mettant un sémaphore dans mes chaines à compiler, les thread d'impression sont envoyés les uns derrière les autres et ne bloquent pas l'utilisateur Merci
-- Dr J-M des Grottes Gestionnaire du Registre des Néphrologues Francophones de Belgique
