Member Avatar for jamello
jamello 158 Posting Whiz in Training

I have a vb.net app. running currently with internet explorer only browsers. I constructed some texts based on the inputs from the user and need to (a) save it on the client file system (b) send the saved file to the printer attached to the client system for printing.

The Security implication is understandable and could be relaxed without fear or threat. if cookies could solve this problem, I cannot successfully implement this with it (cookies).

In detail, (if you wish), I am working with specialized terminals running on windows XP embedded. I have been able to port my app on the server runing on IIS v5 and the terminals can navigate to it successfully. The challenge here to accept input from users, construct this input into a text file save it on the file system on the terminals and then send this file to the specialized printer located and connected to the terminal. Suggestions would be highly appreciated. It would be LIFE SAVING!!!

  • 1 Contributor
  • 0 Replies
  • 126 Views

Dani AI

Generated

For the IE/XPe setup described there are three practical approaches, ordered by reliability and security control.

The recommended approach is a small client-side agent (Windows service or tray app) installed on each terminal. The agent exposes a localhost HTTP endpoint (or custom protocol) that the web page POSTs the constructed text to. The agent saves the file and prints it using the Windows printing APIs (for raw printers use the Win32 WritePrinter path; for normal printers use .NET PrintDocument). Secure the endpoint with a shared secret or local-only binding and open a single firewall exception.

Example client call (browser -> localhost):

fetch('http://localhost:54321/print', {
  method: 'POST',
  headers: { 'Content-Type': 'text/plain', 'X-Auth': 'shared-secret' },
  body: myText
});

If you must stay pure-IE without installing a service, use a signed ActiveX/COM component (or controlled use of Scripting.FileSystemObject) deployed by policy. That can write files and invoke native printing, but it requires relaxed IE security/intranet policies and a code-signing certificate. This is workable on locked terminals but has higher maintenance and security costs.

Notes and tips: browser-only silent printing is not possible reliably—window.print() triggers the dialog. If the printer is network-capable and reachable from the server, server-side printing is an option, otherwise a client agent is needed. For implementation references see the WritePrinter API documentation and ClickOnce deployment notes for signed .NET clients:

Prioritize the agent route for robust, silent printing and easier error handling on XP Embedded terminals.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.