2012-01-26 7 views
6

Antecedentes:supervisión de la impresión Carrete sin utilizar interoperabilidad/código no administrado

Estoy escribiendo una aplicación en C# con .NET 4.0. Imprime un montón de documentos en cierto orden. Los documentos son de todos los tipos y se imprimen utilizando ShellExecute con el verbo "imprimir".

Para asegurarse de que la orden no se complica, me gustaría examinar la cola de impresión para la impresora involucrada. Mi bucle principal se vería así:

"imprimir" acción
  1. invocación en el documento
  2. Espere a que el documento aparezca en la cola de impresión
  3. Repita hasta que esté hecho

¿Cómo puedo controlar ¿La cola de impresión usando el código administrado?

Encontré algunos buenos ejemplos de hacer cosas similares usando llamadas no administradas (Como: http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-a-c-print-spooler-monitor.aspx). Además, sé cómo mirar los archivos en spool bajo c: \ windows \ system32 \ spool ... y resolver las cosas de esa manera.

Sin embargo, ninguna de esas soluciones es muy satisfactoria ... con la cantidad de bacalao no administrado que estoy llamando Siento que debería estar escribiendo la aplicación en C++. (Y no tiene la dependencia/sobre de .NET.)

Pregunta principal: ¿Realmente no hay forma de controlar una cola de impresión utilizando solo llamadas administradas?

Pregunta más general: Vengo del mundo java, y normalmente solo uso lenguajes .NET cuando quiero hacer algo específico de SO o algo que necesita interactuar con otras cosas en el mundo de MS. (Por ejemplo, los componentes de SSIS.)

Parece que cada vez que se inicia un proyecto termino dentro de este mismo desorden: todo tipo de llamadas a funciones nativas, cosas de COM, etc, etc

cuestión secundaria : ¿Hay algo que me falta sobre la filosofía o implementación de .NET? (¿No estoy buscando lo suficiente para que las bibliotecas administradas hagan cosas? ¿Es .NET la opción incorrecta para todo lo que necesita hacer cosas específicas de Windows como manipular la cola de impresión?) Tengo (o creo que entiendo) que .NET Teóricamente se supone que es independiente del sistema operativo ... pero seguramente el sistema operativo más moderno tiene impresoras y colas de impresión y cosas por el estilo. (Así que si había llamadas genéricas para hacer este tipo de cosas, podrían ser implementado en la versión de cada plataforma del marco ..)

+0

¿Por qué los votos a favor? Esta es una pregunta de programación muy específica. La pregunta secundaria, más vaga, es solo un aparte. (Porque parece que la raíz de mi pregunta específica podría ser un malentendido fundamental.) – user426724

Respuesta

5

pregunta principal: Tome un vistazo a la PrintQueue y LocalPrintServer clase en el espacio de nombres System.Printing.

Pregunta secundaria: .NET no se escribió para ser independiente del sistema operativo (sans Mono), se escribió para ser independiente de la versión de Windows. Si bien sería bueno solo tratar con objetos administrados y llamadas administradas, veo esto como una expectativa poco realista. El gran tamaño y volumen de las funciones C y COM existentes expuestas por Windows hace que envolver todo sea una tarea desalentadora. Si bien estoy seguro de que Microsoft tiene toneladas de desarrolladores en la nómina, diría que el retorno de la inversión es bastante bajo para tal empresa, considerando el relativamente fácil de usar COM & P/Invoke disponible.

+0

Suena bien. – Kir

+0

Esto es precisamente * por qué * el soporte COM y P/Invoke se hizo tan disponible y fácil de usar. Solo envuelven las características más comunes. –

+0

Eso, funciona, gracias por la respuesta. @Cody Gray: ¿Eso no niega el objetivo Windows-version-independent? ¿O están asumiendo que la mayoría de las aplicaciones pueden estar construyendo usando solo las características comunes que envuelven? – user426724

Cuestiones relacionadas