locked
Printing in Windows Store Apps

    Question

  • So,

    I am changing this post because my problem is far more complicated (annoying) than originally expected.  If I were creating a WinForms app I would have access to System.Drawing and the Win32 API, but as I am currently trying to create this as a Windows Store app, it renders those possibilities moot.

    The idea is to print a small 1x1 inch to a specific printer.  Now, in the Runtime intrerop functionality I could search for the printer driver and just assign that value to the PrintDocument.  Using a graphics I could just draw the in memory bitmap to the document and send it away.

    However, in this hyper security limited context of the metro interface "store app" I have found so far only Windows.Graphics.Printing and WIndows.UI.Xaml.Printing namespaces.  Though they seem to allow for sending data to a printer thus far I have not found any indication I determine which printer.

    The whole idea is a closed box system, so no extraneous dialogs or user interactions.  They pick the image, set the quanity, and the golden hamster wheel spits out a printed label.

    Now, I can do this very simply in a WinForms application, which I will be working on concurrently so I have a final product to deliver, but for myself (and the client) we would prefer a windows 8 metro style app to do this.  (now if store apps just access the entirety of .Net that would so much simpler, but wishes and horses).

    So could anyone provide me a map for more advanced control of the Printing process from a Windows Store App that I might figure out how to send the print document to the printer I want?

    Thanks

    Jaeden "Sifo Dyas" al'Raec Ruiner

    Monday, April 06, 2015 1:20 PM

Answers

  • Windows Runtime Components (WRC) are Windows Runtime libraries designed for use by Windows Runtime apps. A brokered Windows Runtime Component is a special case available only on side-loaded x86 and x64 systems (so not Windows RT) which can bridge between the Windows Runtime app's container and a desktop process. See Brokered Windows Runtime Components for side-loaded Windows Store apps for more details.

    General purpose Windows Store apps cannot control the printer used. They can provide data to print but require the user to choose the printer. There is no way around this for a store-deployed app or on Windows RT. Controlling the printer requires API that are not available to Windows Store apps.

    For a side-loaded app you can use a Brokered Windows Runtime Component to pass the data to print to a desktop component which can use the desktop API to print.

    Monday, April 06, 2015 6:59 PM
    Owner

All replies

  • It sounds like you have a side loaded kiosk app, in which case you can use a brokered windows runtime component to access desktop printing API and go directly to a specific printer.

    There is no way to force this for a general purpose Windows Store app. For typical use the user is in charge of which printer to use, not the app.

    Monday, April 06, 2015 3:46 PM
    Owner
  • Excellent, thanks for the quick reply.

    For clarification, you mentioned a few terms that i would like to clarify:

    1.  windows runtime component / desktop printing API

    this sound like an actual windows 8 desktop application.  Like what you'd run on windows 7 and windows 8 desktop.  (Full .net 3.5/4/4.5 not the "Windows Store App").  Basically a Windows Forms application / class library / win service maybe?

    2. brokered

    this term sounds like there is a way to communicate from a Windows Metro/Store (XAML) App to a windows desktop component (a process maybe?).  If so, how does one do that.  If I create a WinForms application and create a class library for it.  That class library can be used by any .net application that references it but in the Windows Store App project I can't reference a standard class library, but your use of the term "brokered" suggests there is a way to do this.  Where would I find how to do that?

    3. desktop

    Finally, by the mention of the term "desktop" red flags go up.  I personally will never use Windows RT because it lacks the desktop.  However, by the suggestions you've made here the only way to get my goal seems to be in using Windows Desktop features.  If I were to create the XAML App and the "brokered component" to thus have access to "desktop printing", is that something that will even work on a Windows RT machine?

    Thanks so much,

    J"SD"a'RR




    "Never Trust a computer. Your brain is smarter than any micro-chip."
    PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.

    Monday, April 06, 2015 4:35 PM
  • Windows Runtime Components (WRC) are Windows Runtime libraries designed for use by Windows Runtime apps. A brokered Windows Runtime Component is a special case available only on side-loaded x86 and x64 systems (so not Windows RT) which can bridge between the Windows Runtime app's container and a desktop process. See Brokered Windows Runtime Components for side-loaded Windows Store apps for more details.

    General purpose Windows Store apps cannot control the printer used. They can provide data to print but require the user to choose the printer. There is no way around this for a store-deployed app or on Windows RT. Controlling the printer requires API that are not available to Windows Store apps.

    For a side-loaded app you can use a Brokered Windows Runtime Component to pass the data to print to a desktop component which can use the desktop API to print.

    Monday, April 06, 2015 6:59 PM
    Owner
  • https://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh465204(v=win.10).aspx

    You may refer above URL

    Tuesday, April 07, 2015 12:54 AM