Monitoring Drukuj szpuli bez używania Interop/code niezarządzalny

Question

Tło:

Piszę aplikację w C# za pomocą .NET 4.0. Drukuje kilka dokumentów w określonej kolejności. Dokumenty są różnych typów i są faktycznie drukowane za pomocą ShellExecute z czasownikiem "print".

Aby upewnić się, że zamówienie nie zostanie pomieszane, chciałbym sprawdzić kolejkę drukowania dla drukarki, której dotyczy zgłoszenie. Moim głównym pętla będzie wyglądać następująco:

„print” działania

1. Invoke na dokumencie
2. czekać na dokument, aby pokazać się w kolejce wydruku
3. powtarzać aż zrobione

Jak mogę monitorować Kolejka drukowania przy użyciu kodu zarządzanego?

Znalazłem kilka świetnych przykładów robienia podobnych rzeczy przy użyciu połączeń niezarządzanych (na przykład: http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-a-c-print-spooler-monitor.aspx). Ponadto, wiem, jak spojrzeć na zbiory buforowe pod c: \ windows \ system32 \ spool ... i wymyślić rzeczy w ten sposób.

Jakkolwiek, żadne z tych rozwiązań nie jest bardzo satysfakcjonujące ... z ilością niezarządzanego dorsza, do którego dzwonię, czuję, że powinienem pisać aplikację w C++. (I nie mają zależności/obciążenia .NET).

Główne pytanie: Czy naprawdę nie ma sposobu na monitorowanie kolejki wydruku przy użyciu tylko połączeń zarządzanych?

Bardziej ogólne pytanie: Pochodzę ze świata java i zazwyczaj używam tylko języków .NET, gdy chcę coś konkretnego dla systemu operacyjnego lub coś, co wymaga interakcji z innymi rzeczami w świecie MS. (Na przykład składniki SSIS).

Wydaje się, że przy każdym uruchomieniu projektu I kończy się w tym samym bałagan: wszystkie rodzaje połączeń do natywnych funkcji, COM rzeczy, itp, itd.

Secondary Pytanie : Czy jest coś, czego mi brakuje w filozofii lub implementacji .NET? (Czy po prostu nie szukam wystarczająco mocno, aby zarządzane biblioteki działały? Czy .NET jest złym wyborem dla wszystkiego, co musi robić specyficzne dla Windows rzeczy, takie jak manipulowanie kolejką druku?) Dostaję (lub myślę, że dostaję), że .NET teoretycznie ma być niezależny od systemu operacyjnego, ale na pewno najnowocześniejszy system operacyjny ma drukarki i kolejki wydruku i podobne rzeczy. (Więc jeśli miał połączenia generycznych dla prowadzenia tego rodzaju rzeczy, one mogą być realizowane od wersji każdej platformy ram ..)

Answer 1

Pytanie główne: Spójrz na PrintQueue i LocalPrintServer klasy w przestrzeni nazw System.Printing.

Drugie pytanie: .NET nie został napisany jako niezależny od systemu operacyjnego (sans Mono), został napisany jako niezależny od wersji systemu Windows. Chociaż byłoby miło radzić sobie tylko z zarządzanymi obiektami i zarządzanymi połączeniami, uważam to za nieco nierealne oczekiwania. Sam rozmiar i objętość istniejących funkcji C i COM narzuconych przez Windows sprawia, że ​​owijanie staje się trudnym zadaniem. Chociaż jestem pewien, że Microsoft ma mnóstwo deweloperów na liście płac, powiedziałbym, że zwrot z inwestycji jest dość niski dla takiego przedsięwzięcia, biorąc pod uwagę stosunkowo łatwe w obsłudze wsparcie dla P/Invoke w wersji COM &.