Hi Richard - in the case of my specific app the user’s PC is fully locked down - a Health Care system with very restrictive IT policies.
And FWIW: I use Xojo on Linux with a 100% touch interface, but for “multi-touch” I really don’t have any experience. Here’s a Linux-based product that is running on Xojo-made apps as a touch example. Feel free to hit me up directly if I can be of any touch-screen help for Xojo-Linux.
Surely that wouldn’t extend to device drivers. If they could install drivers, this is a much, much more trivial problem.
Could not agree more - in many cases though when a printer (or other USB device) is plugged in, and is unknown, Windows OS will prompt for Admin credentials - this is something the hospital staff doesn’t have access to. That said, if they don’t configure a printer they can’t print. It is more an issue with “helper app” restrictions. This particular Hospital policy prohibits adding software to any PC.
Yeah, I’ve worked with these folks before. Frankly, I’m surprised that the USB ports on the computer haven’t been filled in with hot glue. The fact that you can connect a USB label printer suggests that you could also plug in a USB flash drive. It’s hard to imagine they would even allow the printer to be connected and used. Has this been tested in any way? It’s possible that they’ve simply disabled the USB ports via software or BIOS.
In any case, it might be time to gently suggest that they start working WITH the IT department instead of around them. I used to do this kind of mediation between creative departments and big corporate IT support systems that didn’t want to support Macs. Usually, if you can present the need in a clear way that middle-to-upper management can buy into, they can pull the right strings to keep the team productive; at the end of the day, the hyper-restrictive policies have to serve both patient privacy AND hospital productivity, and they often end unnecessarily extreme.
I realize this isn’t what you asked and very likely not your role in the situation, but it still had to be said. 
One approach which might get around all of these issues is to use a networked label printer. This would require a few things to be in place: the printer would need to have access to the network, preferably wired, and the web server would need to be able to contact it in order to transmit print data. I’ve used this approach and it can be very effective if you have enough control over the network, etc. It wouldn’t require that the printer be connected to any PC.
It will also layer on a lot of config that has to be performed and maintained – for example, telling the web page which printer to print to, since it sounds like there will be multiple printers. And maintaining the web server->printer(s) network pathway could prove very challenging.
If you need to print without user intervention, then I would suggest that a web app isn’t the right solution. A desktop app communicating with a web api would be much more simple.
…but that’s no fun! 
It’s about being able to deploy to 3000 customers and without installing software on any of their machines. Also known as “Mission Impossible”.
In you have access to webserver and it is a linux box you could utilze CUPS.
It has pretty simple commands to install, retrieve printers. And of course send pdfs to Printer.
But the printer Must Support Network printing of course.
All of that would require admin access… plus these are Windows boxes.
Surely in a fully controlled, secured and managed environment the user will not be allowed to install things, but the IT team will need go there to install what they acquired.
No one can attach a new hardware (label printer) to a machine without installing “some software”: printer drivers and helpers.
If the org expects magic, it will be a no go mission.
Tim’s solution seems to me a good compromise in your case. It’s just a print window to validate after all (a click or press Enter on the keyboard), especially if it doesn’t print anything else from that web browser. And Chrome can print automatically (without a print window to validate) with --kiosk-printing attributes. Still on condition that it doesn’t print anything else from this browser (it can also use one browser just for the App, and another for the rest).
@Tim_Hare , have you ever printed a sheet with lots of labels using this solution? Is the vertical margin between each label respected by the printer? I’m surprised that you don’t have to send a command to the printer so that it can recognize the start of each label. What printer model have you tried? Are we talking about a specialized Zebra or even Dymo printer?
Yes, of course. You just size each label to fit. No special command to start a new label required. I’ve used Zebra and Dymo.
Eric, glue in USB port is not anymore needed with a system policy you can disable file drives to be recognized when inserted to USB ports
I do not know what you mean by not fit for Linux. If you mean real simple with no work then yes.
I am currently working on a RaspPi 5 based on Debian 7" touchscreen app which will replace a dual RV AC/HEAT control system. No keyboard or mouse. After some searching and helpful responses by others on XOJO Forum @Pawel_Soltysinski, @Julia_Truchsess, @Tim_Parnell and @DerkJ then after some trial and error I have the ability to create floating keyboards for various needs and very good on screen controls for the app I am developing.
Okay, so I think the solution might be to incorporate WebHTMLViewer.Print() , where I programmatically create the “label”, render it in the WebHTMLViewer, and then use the built-in WebHTMLViewer.Print() to invoke the Browser/OS printing capability.
HOWEVER… I think I first need to explore (reply with suggestions please!) using the WebGraphics class to draw the label (I will need to place some QR codes on the label too) and save it into a useable graphic file/type for display (and storage).
I’m hoping the (WebApp) workflow could be the following:
WebGraphics object based on the entry, barcode, etc.WebHTMLViewer.WebHTMLViewer.Print().Thanks very much for any advice if this is the correct flow and controls to use.
Circling back - was able to use the built-in QR code (Barcode) functions of Xojo, in the WebApp. Thru some very simple Picture functions was able to accomplish the goal. This is a “zero plug-in” solution. Printing is as simple as loading the Picture into a WebHTMLViewer and calling it’s .Print() function.
How did you solve the problem of no drivers or local software changes? Did IT relent and allow the installation of the label printer and drivers?
Great question! I did have to toss it back on the Customer Site (IT people) to ensure they can print locally from a users station to a label printer. There just isn’t any good way to own that part of the scope - and even if I could I bet it would turn into a support nightmare.
