iDestination() et iAperçu() de fichier texte avec WD8
8 réponses
Réal Phil
Bonjour,
Si on utilise iAper=E7u(iFichier,"FichierTest.txt") ou
iDestination(iFichier,"FichierTest.txt") et qu'on imprime quelques
lignes seulement, le fichier contient chaque fois environ 40 lignes
vides de plus =E0 la fin. Cette situation ne se produit pas avec un
fichier RTF (mais RTF est quand m=EAme la plupart du temps 2 foix plus
gros).
Pour ce qui est de l'impression du fichier txt sur imprimante par la
suite, on peut toujours contourner le probl=E8me en utilisant
SansEspace() comme suit;
sTxt est une cha=EEne=3DfChargeTexte("FichierTest.TXT")
iFen=EAtreAbandon(Faux)
iImprime(SansEspace(sTxt))
iFinImprime()
Mais c'est tr=E8s aga=E7ant, il faut toujours faire tr=E8s attention
partout o=F9 on utilise ces donn=E9es et c'est de l'espace gaspill=E9 -
surtout si on en a plusieurs milliers.
Quelqu'un a une fa=E7on de r=E9gler ce probl=E8me ?
Je suis en WD8 mais est-ce que cela fait la m=EAme chose aussi en WD10
ou 11 ?
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
Réal Phil
De plus, le code suivant ...
iAperçu(iFichier,"FichierTest2.txt") iFenêtreAbandon(Faux) iImprime("Ligne 1: mais pourquoi toutes ces lignes vides dessous?") I est entier POUR I=2 A 75; iImprime("Ligne No "+I); FIN iFinImprime()
... imprime une ligne vide de lui-même entre la ligne 55 et 56...!!??
J'ai alors pensé que, même si je n'utilise pas d'État pour imprimer, WD8 utilise la hauteur du papier par erreur. Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE = 100") ou 200 ou 300... (placé au début du code) rien ne change.
Il n'y a personne qui imprime des factures en WD sur des imprimantes à reçus avec des rouleaux ??
Réal Phil
De plus, le code suivant ...
iAperçu(iFichier,"FichierTest2.txt")
iFenêtreAbandon(Faux)
iImprime("Ligne 1: mais pourquoi toutes ces lignes vides dessous?")
I est entier
POUR I=2 A 75; iImprime("Ligne No "+I); FIN
iFinImprime()
... imprime une ligne vide de lui-même entre la ligne 55 et 56...!!??
J'ai alors pensé que, même si je n'utilise pas d'État pour imprimer,
WD8 utilise la hauteur du papier par erreur.
Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE =
100") ou 200 ou 300... (placé au début du code) rien ne change.
Il n'y a personne qui imprime des factures en WD sur des imprimantes à
reçus avec des rouleaux ??
iAperçu(iFichier,"FichierTest2.txt") iFenêtreAbandon(Faux) iImprime("Ligne 1: mais pourquoi toutes ces lignes vides dessous?") I est entier POUR I=2 A 75; iImprime("Ligne No "+I); FIN iFinImprime()
... imprime une ligne vide de lui-même entre la ligne 55 et 56...!!??
J'ai alors pensé que, même si je n'utilise pas d'État pour imprimer, WD8 utilise la hauteur du papier par erreur. Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE = 100") ou 200 ou 300... (placé au début du code) rien ne change.
Il n'y a personne qui imprime des factures en WD sur des imprimantes à reçus avec des rouleaux ??
Réal Phil
VPSoft
>Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE 100") ou 200 ou 300... (placé au début du code) rien ne change.
Salut,
1) AVANT toute chose, faire d'abord un iRaz
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir "FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI") après FormatPapier. J'ai eu le problème avec Orientation qui n'était pas pris en compte si on ne mettait pas par défaut.
Espérant avoir aidé,
Victor
>Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE 100") ou 200 ou 300... (placé au début du code) rien ne change.
Salut,
1) AVANT toute chose, faire d'abord un iRaz
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir
"FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI")
après FormatPapier.
J'ai eu le problème avec Orientation qui n'était pas pris en compte si on ne
mettait pas par défaut.
>Mais j'ai beau changer la dimension par iParamètre("HAUTEURPAGE 100") ou 200 ou 300... (placé au début du code) rien ne change.
Salut,
1) AVANT toute chose, faire d'abord un iRaz
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir "FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI") après FormatPapier. J'ai eu le problème avec Orientation qui n'était pas pris en compte si on ne mettait pas par défaut.
Espérant avoir aidé,
Victor
Réal Phil
> Salut,
1) AVANT toute chose, faire d'abord un iRaz
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir "FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI") après FormatPapier. J'ai eu le problème avec Orientation qui n'était pas pris en compte s i on ne mettait pas par défaut.
Merci pour les informations, je me serais laissé prendre ailleurs dans le projet. Ça va servir.
Pour ce qui est de ce cas-ci précisément, j'ai fait de nouveaux tests avec ce que tu mentionne et rien ne change dans le fichier FichierTest2.txt créé avec la commande iDestination(iFichier,"FichierTest2.txt"). La ligne vide est toujours entre la ligne 55 et 56 quelle que soit la hauteur de page que je défini avant - même avec la méthode que tu suggère.
Mais comme c'est un cas de redirection vers un fichier texte, je présume que c'est un cas spécial et j'en conclu après tous ces essais que c'est un bug de Windev. Je vais donc utiliser une autre statégie pour contourner le problème.
Ha que j'ai donc hâte de développer 10 fois plus vite! ;-)
Réal Phil
> Salut,
1) AVANT toute chose, faire d'abord un iRaz
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir
"FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI")
après FormatPapier.
J'ai eu le problème avec Orientation qui n'était pas pris en compte s i on ne
mettait pas par défaut.
Merci pour les informations, je me serais laissé prendre ailleurs dans
le projet. Ça va servir.
Pour ce qui est de ce cas-ci précisément, j'ai fait de nouveaux tests
avec ce que tu mentionne et rien ne change dans le fichier
FichierTest2.txt créé avec la commande
iDestination(iFichier,"FichierTest2.txt"). La ligne vide est toujours
entre la ligne 55 et 56 quelle que soit la hauteur de page que je
défini avant - même avec la méthode que tu suggère.
Mais comme c'est un cas de redirection vers un fichier texte, je
présume que c'est un cas spécial et j'en conclu après tous ces
essais que c'est un bug de Windev. Je vais donc utiliser une autre
statégie pour contourner le problème.
Ha que j'ai donc hâte de développer 10 fois plus vite! ;-)
2) Pour que HAUTEUR PAGE soit pris en compte, il faut d'abord définir "FORMATPAPIER = DEFINIUTILISATEUR" (C.f. doc)
3) Si ça marche toujours pas, essayer en ajoutant "iParametre(DEFAUT = OUI") après FormatPapier. J'ai eu le problème avec Orientation qui n'était pas pris en compte s i on ne mettait pas par défaut.
Merci pour les informations, je me serais laissé prendre ailleurs dans le projet. Ça va servir.
Pour ce qui est de ce cas-ci précisément, j'ai fait de nouveaux tests avec ce que tu mentionne et rien ne change dans le fichier FichierTest2.txt créé avec la commande iDestination(iFichier,"FichierTest2.txt"). La ligne vide est toujours entre la ligne 55 et 56 quelle que soit la hauteur de page que je défini avant - même avec la méthode que tu suggère.
Mais comme c'est un cas de redirection vers un fichier texte, je présume que c'est un cas spécial et j'en conclu après tous ces essais que c'est un bug de Windev. Je vais donc utiliser une autre statégie pour contourner le problème.
Ha que j'ai donc hâte de développer 10 fois plus vite! ;-)
Réal Phil
VPSoft
Re-salut,
Tout bien réfléchi, il me semble bien maintenant que la sortie vers fichier Txt n'est qu'une "représentation" de ce qui sortirait sur papier, et pas un "export" proprement dit vers un fichier txt. J'avais effectivement abandonné à l'époque et fait une fonction "export" codée selon chaque cas (lourd !). Donc les lignes vides doivent correspondre à l'espace entre la fin du texte et la fin de page papier.
D'autre part (autre sujet), j'avais abandonné à l'époque (wd55) impression de champs Rtf avec iImprime car : - Rien ne se passait si champ Rtf ne tient pas sur une page A4 - Rtf ne gérait pas les cadres, les bordures, etc.. Est-ce toujours le cas ? Je voulais iImprime pour m'affranchir de Word, pour l'impression de certains documents, dans mes programmes
Victor
Re-salut,
Tout bien réfléchi, il me semble bien maintenant que la sortie vers fichier
Txt n'est qu'une "représentation" de ce qui sortirait sur papier, et pas un
"export" proprement dit vers un fichier txt. J'avais effectivement abandonné
à l'époque et fait une fonction "export" codée selon chaque cas (lourd !).
Donc les lignes vides doivent correspondre à l'espace entre la fin du texte
et la fin de page papier.
D'autre part (autre sujet), j'avais abandonné à l'époque (wd55) impression
de champs Rtf avec iImprime car :
- Rien ne se passait si champ Rtf ne tient pas sur une page A4
- Rtf ne gérait pas les cadres, les bordures, etc..
Est-ce toujours le cas ?
Je voulais iImprime pour m'affranchir de Word, pour l'impression de certains
documents, dans mes programmes
Tout bien réfléchi, il me semble bien maintenant que la sortie vers fichier Txt n'est qu'une "représentation" de ce qui sortirait sur papier, et pas un "export" proprement dit vers un fichier txt. J'avais effectivement abandonné à l'époque et fait une fonction "export" codée selon chaque cas (lourd !). Donc les lignes vides doivent correspondre à l'espace entre la fin du texte et la fin de page papier.
D'autre part (autre sujet), j'avais abandonné à l'époque (wd55) impression de champs Rtf avec iImprime car : - Rien ne se passait si champ Rtf ne tient pas sur une page A4 - Rtf ne gérait pas les cadres, les bordures, etc.. Est-ce toujours le cas ? Je voulais iImprime pour m'affranchir de Word, pour l'impression de certains documents, dans mes programmes
Victor
Real Phil
Re-salut aussi Victor,
Je n'ai pas pu m'empêcher de faire quelques autres tests et tu as bien raison, c'est ma conclusion aussi. C'est à dire que le iDestination() n'est malheureusement pas un export indépendant vers un fichier texte comme je l'aurai pensé mais bien comme tu dis «... les lignes vides doivent correspondre à l'espace entre la fin du texte et la fin de page papier.».
Pour ce qui est du format RTF curieusement lui ne contient pas toutes ces lignes vides et/ou cet espace entre la fin texte et le bord du papier qu'on retrouve dans la redirection texte. En RTF iAperçu(iRTF,"FichierTest.RTF") coupe net juste après la dernière ligne.
Mais je me rend compte qu'on ne peut pas imprimer directement un fichier RTF avec iImprime() et que le nombre d'octets augmente rapidement, beaucoup plus qu'un fichier texte. Alors je ne vais pas continuer mon exploration de ce côté pour l'instant. Surtout que je viens de lire dans l'aide que plusieurs Limitations sont connues dans cette version WinDev 8... au sujet des fichiers RTF. Alors, c'est clair.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc pour me débarrasser de toutes ces lignes vides à la fin. On dirait que SansEspace() fait l'affaire dans la majorité des cas mais pas toujours. Il va falloir que j'analyse ça, il y a peut être des caractères cachés à la fin.
Je dois enlever les lignes de la fin parce que le texte est destiné à être placé dans une rubrique mémo pour être consulté éventuellement à l'écran et/ou imprimé au besoin. Si le fichier texte ne fonctionne pas bien directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin. Curieusement, des commandes existent comme HExporteXML(), HImporteTexte() mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il existe autre chose de similaire?
Ouf! une tâche que je pensais bien simple commence à devenir pénible.
Réal
Re-salut aussi Victor,
Je n'ai pas pu m'empêcher de faire quelques autres tests et tu as bien
raison, c'est ma conclusion aussi. C'est à dire que le iDestination() n'est
malheureusement pas un export indépendant vers un fichier texte comme je
l'aurai pensé mais bien comme tu dis «... les lignes vides doivent
correspondre à l'espace entre la fin du texte et la fin de page papier.».
Pour ce qui est du format RTF curieusement lui ne contient pas toutes ces
lignes vides et/ou cet espace entre la fin texte et le bord du papier qu'on
retrouve dans la redirection texte. En RTF iAperçu(iRTF,"FichierTest.RTF")
coupe net juste après la dernière ligne.
Mais je me rend compte qu'on ne peut pas imprimer directement un fichier RTF
avec iImprime() et que le nombre d'octets augmente rapidement, beaucoup plus
qu'un fichier texte. Alors je ne vais pas continuer mon exploration de ce
côté pour l'instant. Surtout que je viens de lire dans l'aide que plusieurs
Limitations sont connues dans cette version WinDev 8... au sujet des
fichiers RTF. Alors, c'est clair.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc
pour me débarrasser de toutes ces lignes vides à la fin. On dirait que
SansEspace() fait l'affaire dans la majorité des cas mais pas toujours. Il
va falloir que j'analyse ça, il y a peut être des caractères cachés à la
fin.
Je dois enlever les lignes de la fin parce que le texte est destiné à être
placé dans une rubrique mémo pour être consulté éventuellement à l'écran
et/ou imprimé au besoin. Si le fichier texte ne fonctionne pas bien
directement, je vais envisager de placer les lignes à manipuler dans un
fichier HF pour ensuite transférer les info dans un fichier texte au besoin.
Curieusement, des commandes existent comme HExporteXML(), HImporteTexte()
mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il existe
autre chose de similaire?
Ouf! une tâche que je pensais bien simple commence à devenir pénible.
Je n'ai pas pu m'empêcher de faire quelques autres tests et tu as bien raison, c'est ma conclusion aussi. C'est à dire que le iDestination() n'est malheureusement pas un export indépendant vers un fichier texte comme je l'aurai pensé mais bien comme tu dis «... les lignes vides doivent correspondre à l'espace entre la fin du texte et la fin de page papier.».
Pour ce qui est du format RTF curieusement lui ne contient pas toutes ces lignes vides et/ou cet espace entre la fin texte et le bord du papier qu'on retrouve dans la redirection texte. En RTF iAperçu(iRTF,"FichierTest.RTF") coupe net juste après la dernière ligne.
Mais je me rend compte qu'on ne peut pas imprimer directement un fichier RTF avec iImprime() et que le nombre d'octets augmente rapidement, beaucoup plus qu'un fichier texte. Alors je ne vais pas continuer mon exploration de ce côté pour l'instant. Surtout que je viens de lire dans l'aide que plusieurs Limitations sont connues dans cette version WinDev 8... au sujet des fichiers RTF. Alors, c'est clair.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc pour me débarrasser de toutes ces lignes vides à la fin. On dirait que SansEspace() fait l'affaire dans la majorité des cas mais pas toujours. Il va falloir que j'analyse ça, il y a peut être des caractères cachés à la fin.
Je dois enlever les lignes de la fin parce que le texte est destiné à être placé dans une rubrique mémo pour être consulté éventuellement à l'écran et/ou imprimé au besoin. Si le fichier texte ne fonctionne pas bien directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin. Curieusement, des commandes existent comme HExporteXML(), HImporteTexte() mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il existe autre chose de similaire?
Ouf! une tâche que je pensais bien simple commence à devenir pénible.
Réal
VPSoft
Salut,
Surtout que je viens de lire dans l'aide que plusieurs Limitations sont connues dans cette version WinDev 8... au sujet des fichiers RTF. Alors, c'est clair.
Ce que moi j'ai compris depuis un moment, c'est que ce n'est pas parceque Word gére les cadres, bordures etc. en RTF que cela correspond vraiment à la norme RTF. La, c'est un autre débat.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc pour me débarrasser de toutes ces lignes vides à la fin.
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en la mettant par défaut ? Le problème est que Iapercu (semble-t-il) s'appuie, dans une certaine mesure, sur les paramètres de l'imprimante par défaut
directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier Txt avec FecritLigne() pendant le traitement d'impression.
Curieusement, des commandes existent comme HExporteXML(), HImporteTexte() mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il existe autre chose de similaire?
En effet, il n'y en a pas !
Bon courage,
Victor
Salut,
Surtout que je viens de lire dans l'aide que plusieurs
Limitations sont connues dans cette version WinDev 8... au sujet des
fichiers RTF. Alors, c'est clair.
Ce que moi j'ai compris depuis un moment, c'est que ce n'est pas parceque
Word gére les cadres, bordures etc. en RTF que cela correspond vraiment à la
norme RTF. La, c'est un autre débat.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc
pour me débarrasser de toutes ces lignes vides à la fin.
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en la
mettant par défaut ?
Le problème est que Iapercu (semble-t-il) s'appuie, dans une certaine
mesure, sur les paramètres de l'imprimante par défaut
directement, je vais envisager de placer les lignes à manipuler dans un
fichier HF pour ensuite transférer les info dans un fichier texte au
besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier Txt
avec FecritLigne() pendant le traitement d'impression.
Curieusement, des commandes existent comme HExporteXML(), HImporteTexte()
mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il
existe
autre chose de similaire?
Surtout que je viens de lire dans l'aide que plusieurs Limitations sont connues dans cette version WinDev 8... au sujet des fichiers RTF. Alors, c'est clair.
Ce que moi j'ai compris depuis un moment, c'est que ce n'est pas parceque Word gére les cadres, bordures etc. en RTF que cela correspond vraiment à la norme RTF. La, c'est un autre débat.
Un bon vieux fichier texte devrait suffire - mais je dois trouver un truc pour me débarrasser de toutes ces lignes vides à la fin.
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en la mettant par défaut ? Le problème est que Iapercu (semble-t-il) s'appuie, dans une certaine mesure, sur les paramètres de l'imprimante par défaut
directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier Txt avec FecritLigne() pendant le traitement d'impression.
Curieusement, des commandes existent comme HExporteXML(), HImporteTexte() mais pas HExporteTexte(). Bizarre non? Ou bien j'ai mal regardé et il existe autre chose de similaire?
En effet, il n'y en a pas !
Bon courage,
Victor
Real Phil
Salut,
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en
la
mettant par défaut ?
Oui c'était mon essai suivant. Je crois que ça fonctionnerait. Mais mon client sans imprimante aura à faire le même exercice que je voudrais lui éviter. Autre petit problème s'il change sa config de longueur de papier les espaces se retrouverons à des endroits différents selon les longueurs de papier choisi. Les factures sont conservés très longtemps. C'est pas si grave mais juste un peu agaçant. Et surtout pas "Clean" (pas propre).
directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier
Txt
avec FecritLigne() pendant le traitement d'impression.
Voilà la meilleure solution je crois... que j'avais mis de côté parce qu'en utilisant fEcritLigne() je croyais perdre les caractéristiques comme iPolice(), iPosX() et ainsi de suite mais il semble que non par un exemple trouvé sur le forum de PCSoft tard hier soir. Si ça fonctionne comme prévu ça me règle plusieurs problèmes du même coup. Surtout que je viens de réaliser que la facturation dans ce projet pourrait éventuellement servir dans certains cas à générer de très longues factures. Je préfère donc une redirection plus "propre" dès maintenant dans un fichier texte. Alors je fais des essais tout de suite.
Réal.
Salut,
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en
la
mettant par défaut ?
Oui c'était mon essai suivant. Je crois que ça fonctionnerait.
Mais mon client sans imprimante aura à faire le même exercice que je
voudrais lui éviter.
Autre petit problème s'il change sa config de longueur de papier les espaces
se retrouverons à des endroits différents selon les longueurs de papier
choisi. Les factures sont conservés très longtemps. C'est pas si grave mais
juste un peu agaçant. Et surtout pas "Clean" (pas propre).
directement, je vais envisager de placer les lignes à manipuler dans un
fichier HF pour ensuite transférer les info dans un fichier texte au
besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier
Txt
avec FecritLigne() pendant le traitement d'impression.
Voilà la meilleure solution je crois... que j'avais mis de côté parce qu'en
utilisant fEcritLigne() je croyais perdre les caractéristiques comme
iPolice(), iPosX() et ainsi de suite mais il semble que non par un exemple
trouvé sur le forum de PCSoft tard hier soir.
Si ça fonctionne comme prévu ça me règle plusieurs problèmes du même coup.
Surtout que je viens de réaliser que la facturation dans ce projet pourrait
éventuellement servir dans certains cas à générer de très longues factures.
Je préfère donc une redirection plus "propre" dès maintenant dans un fichier
texte.
Alors je fais des essais tout de suite.
Et en déclarant une Nelle imprimante, type "Générique" et "Text only", en
la
mettant par défaut ?
Oui c'était mon essai suivant. Je crois que ça fonctionnerait. Mais mon client sans imprimante aura à faire le même exercice que je voudrais lui éviter. Autre petit problème s'il change sa config de longueur de papier les espaces se retrouverons à des endroits différents selon les longueurs de papier choisi. Les factures sont conservés très longtemps. C'est pas si grave mais juste un peu agaçant. Et surtout pas "Clean" (pas propre).
directement, je vais envisager de placer les lignes à manipuler dans un fichier HF pour ensuite transférer les info dans un fichier texte au besoin.
Dans ce cas, s'il faut coder, autant écrire directement dans un fichier
Txt
avec FecritLigne() pendant le traitement d'impression.
Voilà la meilleure solution je crois... que j'avais mis de côté parce qu'en utilisant fEcritLigne() je croyais perdre les caractéristiques comme iPolice(), iPosX() et ainsi de suite mais il semble que non par un exemple trouvé sur le forum de PCSoft tard hier soir. Si ça fonctionne comme prévu ça me règle plusieurs problèmes du même coup. Surtout que je viens de réaliser que la facturation dans ce projet pourrait éventuellement servir dans certains cas à générer de très longues factures. Je préfère donc une redirection plus "propre" dès maintenant dans un fichier texte. Alors je fais des essais tout de suite.
Réal.
Real Phil
Bonsoir,
Bon, pour ceux que cela pourraient intéresser, qu'on se serve de iDestination() ou iAperçu() pour transférer l'impression dans un fichier texte, et bien vous n'aurez que du texte dans votre fichier. Les iPolices() et iPosX() se verront sur l'imprimante si vous vous servez de iImprime() mais ce qui sera transféré dans le fichier texte ne sera que du texte sans les attributs.
Si on imprime directement dans un fichier texte en se servant de iPosX() et iPolice() et sans passer par iImprime on pourra par la suite imprimer le contenu directement avec iImprime() mais on ne pourra pas visualiser ce même fichier à l'écran dans un champ parce que les caractères de contrôle des iPosX() et des iPolices() se verront dans le champ.
Les champ RTF sont une autre solution mais ont d'autres contraintes aussi. Ils sont beaucoup plus gros et, de plus, plusieurs problèmes non résolus (bugs) sont connus et annoncé par PCSoft dans l'aide en WD8.
On peut trouver d'autres solutions bien sûr, mais pour faire plus simple toute personne qui prévoit utiliser un texte ou un reçu conservé en archive qui servira à la fois à être consulté dans un champ à l'écran et imprimé sur demande a avantage à garder les opérations au plus simple en se servant directement de la création du fichier texte avec fCrée() et de fÉcritLigne().
Réal
Bonsoir,
Bon, pour ceux que cela pourraient intéresser, qu'on se serve de
iDestination() ou iAperçu() pour transférer l'impression dans un fichier
texte, et bien vous n'aurez que du texte dans votre fichier. Les iPolices()
et iPosX() se verront sur l'imprimante si vous vous servez de iImprime()
mais ce qui sera transféré dans le fichier texte ne sera que du texte sans
les attributs.
Si on imprime directement dans un fichier texte en se servant de iPosX() et
iPolice() et sans passer par iImprime on pourra par la suite imprimer le
contenu directement avec iImprime() mais on ne pourra pas visualiser ce même
fichier à l'écran dans un champ parce que les caractères de contrôle des
iPosX() et des iPolices() se verront dans le champ.
Les champ RTF sont une autre solution mais ont d'autres contraintes aussi.
Ils sont beaucoup plus gros et, de plus, plusieurs problèmes non résolus
(bugs) sont connus et annoncé par PCSoft dans l'aide en WD8.
On peut trouver d'autres solutions bien sûr, mais pour faire plus simple
toute personne qui prévoit utiliser un texte ou un reçu conservé en archive
qui servira à la fois à être consulté dans un champ à l'écran et imprimé sur
demande a avantage à garder les opérations au plus simple en se servant
directement de la création du fichier texte avec fCrée() et de
fÉcritLigne().
Bon, pour ceux que cela pourraient intéresser, qu'on se serve de iDestination() ou iAperçu() pour transférer l'impression dans un fichier texte, et bien vous n'aurez que du texte dans votre fichier. Les iPolices() et iPosX() se verront sur l'imprimante si vous vous servez de iImprime() mais ce qui sera transféré dans le fichier texte ne sera que du texte sans les attributs.
Si on imprime directement dans un fichier texte en se servant de iPosX() et iPolice() et sans passer par iImprime on pourra par la suite imprimer le contenu directement avec iImprime() mais on ne pourra pas visualiser ce même fichier à l'écran dans un champ parce que les caractères de contrôle des iPosX() et des iPolices() se verront dans le champ.
Les champ RTF sont une autre solution mais ont d'autres contraintes aussi. Ils sont beaucoup plus gros et, de plus, plusieurs problèmes non résolus (bugs) sont connus et annoncé par PCSoft dans l'aide en WD8.
On peut trouver d'autres solutions bien sûr, mais pour faire plus simple toute personne qui prévoit utiliser un texte ou un reçu conservé en archive qui servira à la fois à être consulté dans un champ à l'écran et imprimé sur demande a avantage à garder les opérations au plus simple en se servant directement de la création du fichier texte avec fCrée() et de fÉcritLigne().
