![]() The “QuickStart Pack” includes a Script editor that can help with that. Inno Setup creates setup.exe installers and is pretty easy to use once you get your script set up. Both will create an installer that can place your app in Program Files, optionally create desktop and Start menu shortcuts, display a license agreement and much more. What are your options?ĭepending on the project, I’ve used two installers on Windows: Inno Setup and Advanced Installer. ![]() This is a great example of how you can use Xojo to quickly, easily, and inexpensively develop highly customized solutions that meet your very specific needs.Now that you’ve finished creating your Windows app, how do you distribute it to Windows users? Microsoft Windows users expect an installer, so you can’t really get away with just using a ZIP file to distribute your apps. And finally, we're able to use a wildcard certificate issued by Let's Encrypt, so our certificate cost is zero. The app is compiled and can run on a low-cost Raspberry Pi device, so the deployment cost is very low. That single instance can serve all of the Tulip workstations. One is that we only need a single instance of the Web app running on the client's local network. There are several benefits of using Xojo for this solution. The Xojo app looks at that header value, and then relays the request to the printer at that address. To determine what printer the request should be sent to, the Tulip custom widget sends the request to the Xojo Web app using a special "X-Relay-To" HTTP header. I then use an instance of the URLConnection class to send an HTTP request to the specified Zebra printer. I'm using the Xojo Web Application framework's "App.HandleURL" event handler to listen for incoming HTTP POST requests and process them. The Web app listens over HTTPS for POST requests, and then routes them to a printer over HTTP. My solution was to use Xojo to develop a custom Web application that essentially acts as a proxy between Tulip and the Zebra printers. However, the printer model mentioned is what my client is using - and this solution seems less than ideal, because we'd need to load certificates on to each of my client's printers, and also renew them. There's a solution mentioned in that post, which involves loading an SSL certificate on to the Zebra printers. While researching the issue, I stumbled upon this post. This request has been blocked the content must be served over HTTPS. ![]() Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ''. ![]() The error that I could see via the Tulip console was: The issue that I ran into had to do with " mixed content." The Tulip app is essentially a Web app that is served up over HTTPS, while the Zebra printers are only designed to accept HTTP requests. Additionally, this will give them the option to print specific labels on printers that are setup with the necessary label types. If a printer becomes unavailable for some reason, the operator will be able to route requests to an alternate printer. My client is using the HTTP method, which allows then to easily route print requests to specific printers in their warehouse. These printers can be connected to workstations using USB cables, where print requests are sent directly, or connected wirelessly, where requests are sent as HTTP POST requests. While working on the project, I ran into an interesting and challenging issue involving printing to their Zebra printers. The app tightly integrates with NetSuite, and makes heavy use of Tulip custom widgets. I'm using Tulip to build an app that will help streamline my client's manufacturing process, including the picking of parts, the build process, quality control and inspection, packing, and more. One of the projects that I've been working on recently is a "reboot" of a client's Tulip implementation.
0 Comments
Leave a Reply. |