OCX - APERÇU AVANT IMPRESSION
cs_NISANDSYSTEMS
Messages postés
178
Date d'inscription
vendredi 1 novembre 2002
Statut
Membre
Dernière intervention
9 janvier 2010
-
16 nov. 2004 à 20:12
thierrybardin Messages postés 4 Date d'inscription mardi 11 mai 2004 Statut Membre Dernière intervention 7 septembre 2005 - 7 sept. 2005 à 14:19
thierrybardin Messages postés 4 Date d'inscription mardi 11 mai 2004 Statut Membre Dernière intervention 7 septembre 2005 - 7 sept. 2005 à 14:19
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/27605-ocx-apercu-avant-impression
https://codes-sources.commentcamarche.net/source/27605-ocx-apercu-avant-impression
7 sept. 2005 à 14:19
Petite question : peux t'on imprimer un texte avec un FOND blanc (genre on a definit le setbackcolor et on souhaite ecrire un texte mais sans le fond (comme un formulaire par ex.)
6 mai 2005 à 11:22
J'ai crée moi aussi un état d'impression moins complet que celui-ci mais suffisant pour mon utilisation personnel, au vu des premiers commentaires j'ai noté apparement qu'il est préférable d'envoyer directement une image à l'impression plutot que tout dessiner ce que je fais habituellement car plus simple pour moi à gérer.
Mais lorsque cette image est le résultat du contenu d'un picturebox dans lequel j'ai tout dessiné (police, rectangle, image de fond etc...) je me rend très vite compte lors de l'impression que la police est pixelisée à mort et que le résultat n'est pas toujours celui espéré.
J'en viens donc à ma question est-il possible d'appliquer un effet de lissage sur une image que l'on souhaite imprimer au moyen de strechblt ou de tout autre méthode ??
Dernière chose, qui sait comment gérer ces foutus marges d'impression car bien que l'imprimante en ai besoin, il existe quand même des formats de papier (genre étiquettes) dont les dimensions sont nettement supérieures aux marges de toutes ces imprimantes ??
Sinon j'allais oublié le plus important 10/10 à cette source quand même :-)
@plus
20 nov. 2004 à 16:46
Je tâcherai donc d'éplucher le code plus en avant.
Bonne continuation...
20 nov. 2004 à 12:51
20 nov. 2004 à 12:49
l' OCX (dessine) tout ce qui bouge.
Donc pour le texte il prend tout aussi bien les Tabulation que le CRLF. Bien sur il ne gere pas le wordwrap ( ce n'est pas un editeur de texte ) mais tu peux le traiter avant dans ton code.
Pour l'orientation, il gere le portrait et le paysage.
Pour le placement des objets, tu as toutes les coordonées et les marges a ta disposition (sachant que tu les renseignes a l'initialisation).
Pour ta derniere question, comme tu le dis, tu dois tracer des lignes et dessiner du texte donc oui le code a des fonctions rapide pour faire ca.
J'ai noter dans mes idees d'ameliorations, la possibilité de faire des tablos mais ca reste plutot complexe et j'ai quelque peu du mal a negocier une technique relativement simple a utiliser et assez puissante pour faire qqc de sympa (la gestion des cellules c le merdier).
Deplus si ton "tableau" tu le dessine sur ton picture box, il sera tres tres simple de l'imprimer !!
OCX.PaintPicture Page, LaPicDeTonTablo.image, .. ... .....
et ca tu le fait dans le sens que tu veux et tu met le mode mAuto pour que l'ocx le redimmenssionne tout seul au format de la page (format de page directement renseigné a linitialisation du code - dans mon exemple j'ai pris le format de la page actuel de l'imprimante par defaut)
20 nov. 2004 à 12:11
Je planche actuellement sur une application de gestion d'horaires.
J'ai coder entièrement l'impression des grilles horaires de manière à avoir un "tableau" avec les horaires du personnel pour une semaine complète. Au niveau code, il s'agit donc de texte sur lequel je trace des lignes pour réaliser les différentes cases.
Ton code permet-il de présenter un aperçu avant impression de ces feuilles ?
20 nov. 2004 à 12:07
Par manque de temps, je n'ai pas encore étudier le code, mais je souhaiterais poser quelques questions.
Est-ce que le code permet de choisir l'orientation de l'impression (portrait-paysage) ?
Est-il envisageable de permettre une double utilisation de cette orientation ? Imaginons un rapport dans lequel on souhaite intégrer un graphique au milieu : le texte serait en portrait et le graphique en paysage.
Autre question, tu "joues" avec les images mais qu'en est-il du texte ? Pour revenir sur mon idée de rapport, faut-il taper le texte "ligne par ligne" ou le contrôle prend-t-il en charge la gestion d'un texte complet (lignes, paragraphes, interligne...) ?
Au plaisir de te lire...
18 nov. 2004 à 12:55
et surtout la gestion de memoire est totalement inefficace dans ce genre là.
Un exemple parmi tant d'entre;
Envoie vers la DLL, l'image a traiter et non un string ou autre type comme beaucoup font.
A partir de là le traitement peu commencer sans pour autant gener l'application client.
Une fois le traitement terminé; renvoie l'image son application type picturebox
Je vais me pencher dessus et te tiens au courant
@+
18 nov. 2004 à 10:58
Avantage, perte de qualité moindre
Incovenient, lenteur de traitement accrue
Mais c'est en reflexion car l'apercu avant impression, c'est super utile mais ca reste du domaine du mystere sous vb6 :/
18 nov. 2004 à 10:43
Pour le zoom, tu peux retranscrire tous les parametres du Picturebox,
type height,width etc... via un ctl Image et ensuite appliquer l'effet sur le ctl Picture, qui à mon sens et loin d'etre le meilleur ctl pour la getion de memoire et surtout en VB
17 nov. 2004 à 09:17
En fait je suis obligé de revoir le positionnement de chaque page de maniere automatique ce qui me permetterai de reduire les page a taille souhaitée.
Autre bemole, etant des picturebox "dessinée" je suis obligé de zoomer/dezoomer les image avec les apis ce qui fait a force de zoomer/dezoomer, on perd un max de qualité ....
Il faut donc que je revoie une bonne partie du code, mais bon :) c'est en cours !
Merci pour la note :)
16 nov. 2004 à 20:12
Pour le reste, chacun sa sauce suivant ce qu'il veut...
10/10