WindowsAppSDK
WindowsAppSDK copied to clipboard
microsoft
Proposal: Allow the App to Print without showing the Confirmation Dialog to user
Proposal: Allow the App to Print without showing the Confirmation Dialog to user
Summary
We should be able to programatically list printers, select the printer, configure paper size, orientation, settings... and PRINT without user interaction.
Rationale
I was trying to make a Touch Screen Kiosk Receipt Print application on UWP, but the samples show
await Windows.Graphics.Printing.PrintManager.ShowPrintUIAsync();
This brings the UWP Print Dialog.
I need to print directly without this dialog. How to do this?
I need something like
await Windows.Graphics.Printing.PrintManager.PrintAsync();
We should be able to programatically list printers, select the printer, configure paper size, orientation, settings...
This will enable:
- Enable easy printing from Voice / Touch applications
- Make the printing API more complete, like the WPF Printing API was.
- This Permission will be very useful for ATM Applications, Touch Screen Kiosk Apps, Barcode Printing Software, Point of Sale applications, Line-of-Business Applications, etc;
Scope
| Capability | Priority |
|---|---|
| This proposal will allow developers Print without user interaction. | Must |
| This proposal will allow the App to Configure Paper Size | Must |
| This proposal will allow the App to Set Page Orientation | Must |
| This proposal will allow the App to List printers | Must |
| This proposal will allow end users to give the Printing without interaction permission on app install (AllowPrintingWithoutUserIteraction) | Should |
| This proposal will allow the App to Change the Default Printer | Could |
| This proposal will allow the App to set Printing Settings like Color, Grayscale, Draft | Could |
Important Notes
This may require the creation of a new permission/capability for UWP AppModel: AllowPrintingWithoutUserIteraction
Open Questions
A separate capability for this would be good because it makes it clear that this is a special scenario, should be treated differently, and is probably not for everybody.
Even with this setting/capability I still think there's value in the user having to opt-in to silent printing through the UI once. This will avoid any app from surprising users by printing without ever showing any UI indicating that it wants to print. This would be comparable with requesting location or other potentially sensitive information that the user may not want.
This should also be an app level setting that can be revoked in future if the user desires.
For scenarios like kiosks that need to print and not desktop style apps that are more likely to be used by a single person for longer, such devices/apps still need initial configuration which would include testing the printer configuration and therefore enabling this setting.
It could be a permission that only presents it's permission dialog on the first programmatic print - rather than just at install, or first run of the app.
I suppose that this will be useful to enable to use Windows10X with UWP instead of Win32, for those scenarios.
I also sent a message about this to Stefan Wick, he said: ... Not a WinUI limitation, but a limitation of the appmodel you chose. When you build a WinUI app with Win32 appmodel it will work, but not with UWP appmodel. https://twitter.com/StefanWickDev/status/1240099309204287488
But anyways, I believe that the WinUI team can redirect this request, as this is required to increase the success of the WinUI, allowing it to be used in more scenarios, like the ones that I described.
@TonyHenrique IMO you are correct in posting this issue here even if it's not directly WinUI related. There is just no other platform out there right now to discuss UWP app model/WinRT improvements and where we can be confident at least someone from MS will take a look at it and redirect it internally if required (yes, MS keeps repeating they listen to feedback even in the feedback hub but the perception of the feedback hub among the community is really bad). The WinUI team recognizes this feedback platform issue and thus tolerates community input discussing (fundamental) UWP issues.
I know this is further out of scope, but it may be worth looking at a possible opt in permission system for WinUI Desktop. Giving the user peace of mind, without the Win32 free for all, and less restrictive than UWP.
Either creating new sets of permissable actions, or a way to detect if an action could be abused, and display a general "Are you sure you want to do XXXX" permission. With Just Once Always and Never options.
This is very similar to existing issue #52, but has more detail. @awsomecode would you mind if we made this the primary since it has the "proposal" format with details? What else would you want to add to the proposal?
@jonwis Ya, this one will cover my requirement as well. You can make this primary.
@TonyHenrique FYI we do not show consent prompts on install[1]; we show them on first-use (more correctly: the first time the app requests the permission, which might be before it actually "uses" it, depending on how the app is written and the specific API in question). Otherwise, agreed that this feature would need a permission that the user could consents to and can later change their mind in Settings.
[1] We do perform a UAC prompt for anything that impacts the machine / other users during install.
This wont be available on WinUI3 ?
Printing without confirmation requires work at the security / isolation level, not just the UI level.
This is so much import for retail softwares. Without this we can't convert WPF apps to UWP/WinUI3
@AwsomeCode You should be able to print without a UI confirmation dialog if you will port your WPF apps to WinUI 3 desktop apps. @ptorr-msft's comment is about (WinUI 3) UWP apps (since the requested change will require changes in the UWP app model implementation and that's not something WinUI is responsible for).
I'm trying to build a POS application with UWP, can't get the POS to recognize the cheaper thermal printers out there, I'm waiting on this to be realeased so I can properly deal with the printers that are not supported by the POS namespace.
@Rothanan can you share the details of the printers that don't work? Are they specifically sold as POS devices that adhere to the POS standards?
@ptorr-msft this are the few I have tried. https://www.atpos.in/product/atpos-usb-bluetooth-e-200-portable-thermal-receipt-printer/ https://www.atpos.in/product/atpos-hop-h58-58mm-thermal-receipt-printer/
Surprisingly they work with Android. But not with UWP.
I wonder how macOS deal with such issue. Is there a "print permission", or apps are allowed to print without confirm?
@ptorr-msft they are very basic printers, they only work through ESC/POS. I can get them working on android, but not in UWP:
Here's a model: https://www.amazon.com/Wireless-Bluetooth-MUNBYN-Portable-Compatible/dp/B07N86DR4J
They are sold mainly as mobile bluetooth thermal printers(they also come with an usb conection) and because they are cheaper most customers wanna buy and use them.
POS printers, sounds like an IOT device situation, and that supports device drivers right? Which would allow direct talking to the printer device right?
Yeah, you're right, in android devices, all I do is send ESC/POS commands directly to the printer.
I'm looking for a way to do the same in UWP, in a Desktop environment.
@Rothanan thanks for the info; I will send to the POS team internally to see if they know of any issues with these devices.
Sorry @AwsomeCode , some rather urgent personal stuff came up and I've been distracted. Tracking them down now and will pass along. Thanks for the reminder.
Can you confirm if you are using the POS APIs or the regular printing APIs?
In UWP Its not POS APIs or Regular Printing API. I have tried RawPrint Which sends RAW ESC/POS data commands to printer and it print silently on printer. It works in debug mode. But on published app its not allowed. For published app we have to use Desktop Extension for UWP. Which is not best experience in development. (Our UWP app never get approved in store. They say its crashing and In our machines its working fine.)
In Android Sending RAW ESC/POS data commands via Bluetooth and its gets print silently.
In iOS Printer is not getting connected via Bluetooth.
Below are the printers I am referring to. https://www.atpos.in/product/atpos-usb-bluetooth-e-200-portable-thermal-receipt-printer/ https://www.atpos.in/product/atpos-hop-h58-58mm-thermal-receipt-printer/
I have tried RawPrint Which sends RAW ESC/POS data commands to printer and it print silently on printer. It works in debug mode. But on published app its not allowed.
That project says it relies on .NET 4, which isn't supported for UWP apps (only .NET Native is supported). Can you pair the printers first and then use the POS API?
I have tried this sample project it did not worked. https://docs.microsoft.com/en-us/samples/microsoft/windows-universal-samples/posprinter/
Can you confirm if you are using the POS APIs or the regular printing APIs?
I tried using the POS API, it doesn't recognize the ESC/POS printer, the POS API support very few printers which renders it unusable.
We are just looking for a away to send ESC/POS commands to ANY printer that understands it.