|
| Imprimer un etat en Wlangage |
| Débuté par lachap, 30 mai 2015 17:13 - 3 réponses |
| |
| | | |
|
| |
Membre enregistré
36 messages
Popularité : +2 (2 votes) |
|
Posté le 30 mai 2015 - 17:13 |
Bonjour à tous.
Je rencontre un problème avec l'impression d'un état avec aperçu :
Version de WinDev 01F200051m.
Il s'agit d'un document de quelques lignes qui tient largement sur une page avec un pied de page.
Quand je lance l'impression (iImprimeEtat) Il arrive quelque fois que l'aperçu contienne un nombre variable de pages
(85, ou 87 ou 95 par ex.) avec le pied de page apparaissant sur la dernière.
Il arrive d'autres fois que l'aperçu ne contienne qu'une page mais lorsque je lance l'impression depuis l'aperçu,
il y a génération de n page vers l'imprimante (je ne sais pas combien car j'ai interrompu le traitement dans ces cas)
Il arrive quelque fois que ça marche
A l'utilisation, ces phénomènes semblent aléatoires, ou du moins je ne perçois pas les conditions de déclenchement.
En cours de debuging en exécution pas à pas il m'est arrivé 1 fois de voir le traitement Haut_depage de l'état s'exécuté en boucle. Mais quand j'ai voulu reproduire ce phénomène, rien à faire.
En complément, la fonction "iFinImprime" semble être inutile :
- présente ou pas dans le programme appelant l'état, les phénomènes ci-dessus se produisent toujours.
- présente ou pas dans la fin d'état idem.
voici le code d'appel de l'état :
iParamètreAperçu(iBoutonImprimante + iBoutonEmailPdf)
iParamètreDuplicata(iDplImpression, sPathFichier, sNomFichier)
iDestination(iImprimante)
iAperçu(iapZoomLargeurPage,"Affaire N° " + SAI_AffaireNum + " - " + LIB_Personne)
iImprimeEtat(ETAT_FactureClient,gTypeDoc,gsNumFactureEncours,gbProFormat,gnIDAdresse,SAI_DéjàVersé)
Sablier(Faux)
Quelqu'un a-t-il déjà rencontré un problème de cette nature.
Merci pour vos idées
Cordialement
Laurent Chapuis |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
36 messages
Popularité : +2 (2 votes) |
|
Posté le 30 mai 2015 - 19:11 |
En complément des informations données ci-dessus, dans un nouvel essais, j'ai reçu le message suivant :
"Une erreur est survenue dans la fenêtre FEN_FactureClient
Votre code à provoqué un dépassement de la pile d'exécution
avant impression de HAUT_DE_PAGE
Ligne 65535"
FEN_FactureClient, c'est le programme appelant l'état.
HAUT_DE_PAGE comme son nom l'indique appartient à l'état appelé.
Ceci confirme ma précédente observation sur le HAUT_DE_PAGE.
Mais comment trouver la/les variable/s qui déterminent ce phénomène.
En désespoir de cause, je charge cette nuit la mise à jour 01F200057k.
Cordialement
Laurent Chapuis |
| |
| |
| | | |
|
| | |
| |
Posté le 30 mai 2015 - 19:21 |
Bonjour Laurent
les seules fois ou j'ai vu ca, c'était parceque mon état essayait
d'imprimer dans la marge technique de l'imprimante (zone ou elle ne peut
PAS imprimer)... La solution était simplement d'augmenter les martges de
l'état
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com
On 5/30/2015 9:13 AM, lachap wrote:
Bonjour à tous.
Je rencontre un problème avec l'impression d'un état avec aperçu :
Version de WinDev 01F200051m.
Il s'agit d'un document de quelques lignes qui tient largement sur une
page avec un pied de page.
Quand je lance l'impression (iImprimeEtat) Il arrive quelque fois que
l'aperçu contienne un nombre variable de pages
(85, ou 87 ou 95 par ex.) avec le pied de page apparaissant sur la
dernière.
Il arrive d'autres fois que l'aperçu ne contienne qu'une page mais
lorsque je lance l'impression depuis l'aperçu,
il y a génération de n page vers l'imprimante (je ne sais pas combien
car j'ai interrompu le traitement dans ces cas)
Il arrive quelque fois que ça marche
A l'utilisation, ces phénomènes semblent aléatoires, ou du moins je ne
perçois pas les conditions de déclenchement.
En cours de debuging en exécution pas à pas il m'est arrivé 1 fois de
voir le traitement Haut_depage de l'état s'exécuté en boucle. Mais quand
j'ai voulu reproduire ce phénomène, rien à faire.
En complément, la fonction "iFinImprime" semble être inutile :
- présente ou pas dans le programme appelant l'état, les phénomènes
ci-dessus se produisent toujours.
- présente ou pas dans la fin d'état idem.
voici le code d'appel de l'état :
iParamètreAperçu(iBoutonImprimante + iBoutonEmailPdf)
iParamètreDuplicata(iDplImpression, sPathFichier, sNomFichier)
iDestination(iImprimante)
iAperçu(iapZoomLargeurPage,"Affaire N° " + SAI_AffaireNum + " -
" + LIB_Personne)
iImprimeEtat(ETAT_FactureClient,gTypeDoc,gsNumFactureEncours,gbProFormat,gnIDAdresse,SAI_DéjàVersé)
Sablier(Faux)
Quelqu'un a-t-il déjà rencontré un problème de cette nature.
Merci pour vos idées
Cordialement
Laurent Chapuis |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
36 messages
Popularité : +2 (2 votes) |
|
Posté le 09 juin 2015 - 19:59 |
Merci Fabrice.
Mais le problème n'était pas là. Voici ce que j'ai trouvé :
Dans mon fichier, il y a une rubrique stockant un texte en mode RTF, c'est à dire le texte encadré par les commandes du mode RTF.
Or il s'avère que certaines fois, le texte saisi par l'utilisateur est long. Le nombre de caractère (la taille du texte + la taille des commandes RTF).
est alors trop long pour ma rubrique de 500 caractères et la fin du texte est tronqué. Pas de pot il s'agit de la fin des commandes RTF.
Et lors de l'impression, c'est le bazar.
Si j'ajoute à la main (Centre de contrôle HFSQL) les caractères manquant "\par" + RC + "}" + RC
tout rentre dans l'ordre.
Morale : quand vous manipulez du texte en mode RTF, la rubrique de stockage doit pouvoir contenir le texte + les commandes RTF.
J'espère que ceci rendra service à d'autres.
Cordialement
Laurent |
| |
| |
| | | |
|
| | | | |
| | |
|