Toon posts:

[C#] PDF printen en foutafhandeling

Pagina: 1
Acties:
  • 334 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Beste tweakers,

Situatie
Ik ben bezig met een facturatiesysteem dat vanuit een database facturen opmaakt naar PDF formaat. Dit opbouwen doe ik via de library SharpPDF. Ik wil nu per klant de factuur printen die uiteindelijk uit het proces komt. SharpPDF biedt hiervoor mogelijkheden.

Probleemstelling
SharpPDF biedt de mogelijkheid om een factuur te printen. Dit gaat echter, zoals veel libraries, door Adobe Reader via de commandline aan te roepen. Het voordeel is dat de specialist (Adobe Reader) de afhandeling van het printen doet. Het probleem is dat ik, zover ik weet, geen feedback kan krijgen uit die aanroep. En vaak als dat al wel het geval is dan is dit geen gedetailleerde informatie zoals je normaal uit bijvoorbeeld een exception zou krijgen.

Geprobeerd? Alternatieven?
1) SharpPDF zoals hierboven
2) Enkele opensource libraries maar bieden dezelfde commandline-achtige manier

Alternatief 3) Oproep naar een PDF printer sturen. Dit lijkt mij echter hetzelfde probleem te geven als een commandline omdat je nog geen duidelijke informatie kan afvangen. Wellicht zelfs met de Windows API ?

4 ) Inmiddels iets nieuws: COM Object via SharpDevelop toevoegen aan het C# Project. Deze AcroLib heeft een AcroPDF met verschillende printfuncties. Deze printfuncties hebben alleen een void return. Nu is er wel een .add_onError(...) functie. Iemand ervaring mee? Weinig documentatie te vinden.

Voor zover ik weet zijn er geen vrije libraries die een betere manier aanbieden.

Vraagstuk
1) Hoe kan ik het beste PDF bestanden afdrukken waarmee ik fouten die tijdens het printproces, voor kunnen komen , kan afvangen? Om zeker te weten dat alles is uitprint voordat ik deze bevestig in de database.

[ Voor 9% gewijzigd door Verwijderd op 25-04-2007 11:46 ]


  • Sallin
  • Registratie: Mei 2004
  • Niet online
Wat zijn dingen die fout kunnen gaan? Printer off-line, out of paper oid? En kan je daar zelf al voor controleren voordat je het printverzoek doet?

This too shall pass
Debian | VirtualBox (W7), Flickr


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 08:30

gorgi_19

Kruimeltjes zijn weer op :9

.

[ Voor 99% gewijzigd door gorgi_19 op 25-04-2007 11:12 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


Verwijderd

Topicstarter
Dat zijn inderdaad punten die fout kunnen gaan:

1) Papier op [ misschien is via een Windows API te controleren welke status de printer heeft? ]
2) Geen verbinding [ gaat nu via Adobe Reader, krijg ik geen reply van ]

Een printerverzoek gaat op dit moment dus indirect via mijn systeem en direct via Adobe Reader omdat die echt PDF kan printen.

  • masterpoi
  • Registratie: Oktober 2004
  • Laatst online: 01-12 17:47
Omdat je PDF gebruikt heb je uiteraard een programma of library dat een PDF kan renderen nodig om het af te drukken. Voor zover ik weet zijn er geen open-source of gratis PDF-renderes voor .NET beschikbaar, je moet dus altijd via een extern programma gaan. Controle vanuit een .NET taal over de printfunctie van zo'n programma (Acrobat, Foxit, ...) bestaat ook niet.


Ik zie drie oplossingen:

1. Een third-party managed-code pdf renderer aankopen.
2. De PDF printen via Acrobat en dan via de nieuwe System.Printing API in .NET 3.0 controlleren of de job uit de printer gerold is.

Zie hier: http://msdn2.microsoft.co...rary/system.printing.aspx

Je moet aan een PrintServer object het juiste PrintQueue-object opvragen, deze heeft heel wat intressante properties/methodes: http://msdn2.microsoft.co...rary/system.printing.aspx

3. Je formulier in XPS opstellen en via System.Printing afdrukken. (De API daarvoor is sterk vergelijkbaar met sharpPDF). Met deze methode heb je buiten .NET niets extra's nodig.
Voor veel meer info kijk hier: http://msdn2.microsoft.com/en-us/library/aa970909.aspx

  • johanmulder
  • Registratie: Augustus 2002
  • Laatst online: 18-11 21:38

johanmulder

Nederlands Ondertiteld

Het probleem is dat je hier te maken hebt met externe factoren, in dit geval de hardware (printer). Het lijkt mij de meest nette oplossing om de gebruiker eerst te vragen of de PDF goed geprint is en dan vervolgens de databaseacties uit te gaan voeren (of niet).

Werkt met: Apple Macbook Pro 16" | Bouwt: Multi-cloud SaaS-oplossingen | Vader | Wereldreiziger | Rijdt: Mercedes GLC


  • masterpoi
  • Registratie: Oktober 2004
  • Laatst online: 01-12 17:47
johanmulder schreef op donderdag 26 april 2007 @ 11:12:
Het probleem is dat je hier te maken hebt met externe factoren, in dit geval de hardware (printer). Het lijkt mij de meest nette oplossing om de gebruiker eerst te vragen of de PDF goed geprint is en dan vervolgens de databaseacties uit te gaan voeren (of niet).
Gesteld dat je de gebruiker vertrouwd natuurlijk ;)
Pagina: 1