Page 1 of 1
Controlling Printers and Scanners
Posted: Thu Aug 02, 2012 6:45 pm
by stephenmcnutt
I'd like to create a LiveCode desktop (Windows/Mac, not iOS) app that can tell a scanner to scan a user's ID card, can get the image from the scanner, and can tell a label printer to print. In other words, I need to interface with the scanner and with the printer.
I don't really know where to start, though. I don't even know the vocabulary to begin searching for answers. Thanks for any help you can offer.
Steve
Re: Controlling Printers and Scanners
Posted: Tue Aug 07, 2012 3:07 am
by Cool Dave
Hi Steve,
I'm not sure whether LiveCode supports scanning natively, but you could certainly use an open-source program to get the image, then import it into your app. I've never seen anyone do scanning in LC before.
Printing is fairly simple, although it's trial and error to get just what you want. This is a snippet from I've used before. Or just search for 'print' in the dictionary.
Code: Select all
set the printMargins to 36,36,36,36
set the printScale to .90
open printing with dialog
print card "card1"
print card "card2"
close printing -- send group of cards to printer
Regards,
Dave
Re: Controlling Printers and Scanners
Posted: Tue Aug 07, 2012 3:36 am
by sturgis
Are you using a dymo label printer? (all of the following assumes you're on windows)
If so, you can download the dymo sdk and get it installed (required for the method i'm about to describe)
Once you have the dymo sdk installed, create a barcode label. For example a barcode with 2 labels. 1 named TEXT the other named BARCODE. Save the label template to a file.
I named my label mike.label
Once the label is created, I put the following into a property of my stack.
Code: Select all
Dim DymoAddIn, DymoLabel
set DymoAddin = CreateObject("DYMO.DymoAddIn")
set DymoLabel = CreateObject("DYMO.DymoLabels")
DymoAddIn.Open("[[tPath]]")
ret = DymoLabel.SetField("TEXT","[[pName]]")
ret = DymoLabel.SetField("BARCODE","[[pCode]]")
DymoAddIn.Print 1, TRUE
From the above, the first 2 set lines get things ready to print to the label. (connecting to the dymo sdk)
The open line opens a label file (the path to the label file is merged in on execution.
The 2 ret lines set up a record for the loaded label, specifying field name and the value. (the value is merged in later)
Finally the print line prints. 1 stands for 1 copy (if I recally correctly) I forget what the TRUE is for, its been a while.
Code: Select all
-- Again, its been long enough that I don't remember WHY I had to do this
-- but it works and i'm sure I had a reason. :) (do vbscripts require double \\ in path names?)
-- also note, rev likes / for the path delimiter (even on windows) but vbscript expects \ so
-- make sure you're sending the correct path and delimiter.
replace "\" with "\\" in tPath
-- grabs the property (bcodeprint) that I stored the above vbscript in..
-- merges in tPath, pName, pCode variables into their placeholders, then runs the vbscript
-- voila' out pops a label.
do merge(the bcodeprint of this stack) as "vbscript"
Re: Controlling Printers and Scanners
Posted: Fri Aug 24, 2012 2:45 pm
by stephenmcnutt
Thanks, Sturgis. I'm NOT on Windows, though. The app I intend to write will be run on a Windows machine, but I only have the Mac OS X development rights with deployment rights to Mac and Windows. Am I screwed? Thanks again for your reply.
Re: Controlling Printers and Scanners
Posted: Fri Aug 24, 2012 4:15 pm
by sturgis
Well first, unless i'm mistaken the only part that matters is the "deployment" rights. Unless things have changed you can develop on any platform (linux, windows, mac) but can only build for the deployments you have rights to. At my home (i'm a hobbyist) I run the ide on linux (both vm and real machine) 2 windows laptops, a windows desktop, and recently managed to scrounge enough together to get a mac again. THe ide is installed on all of these. The license is based on ownership not machine. On the other hand when I do stuff for places in town, I dev on my machines and build standalones since I don't own those machines and don't have right to put the ide on them. Of course, confirm that things haven't changed before you put the ide on multiple machines but i'm pretty sure things have not changed in that respect.
Now, you say its going to be run on a windows machine? If this is a one-off development, and you have control of the windows machine and can install the sdk as I mentioned (AND you are using a dymo label printer..) then I don't see why you couldn't make it work. You wouldn't be able to test on the mac live and would have to do some work on the windows machine.
On the windows machine, create the label(s) you wish to use and save them as label files (basically they're just xml files, you could probably whip up a way to build label files on the fly in your app) Once the labels are created, you have the field names and can use vbscript to send the data to the sdk which will then print the labels with the sent data. It will be more of a pain to test since you won't be able to test live on the mac. One way to ease things would be to set up a very simple stack where you can click a button to choose a label file, and another button to execute vbscript code from a field. This way on can set up a basic framework, type in the vbscript you want to test into the field and test it, adjust, test. Once you figure out how the vbscript and label files work, go back to the mac and build your real application. (of course if the windows machine is owned by you, then you're back to the option of developing on it directly)
Re: Controlling Printers and Scanners
Posted: Sat Aug 25, 2012 3:48 pm
by stephenmcnutt
Wow. Thanks for taking the time to write such a thoughtful and helpful reply, sturgis. I'll give your suggestions a try. I'm just a hobbyist, too. I started my main "life's work" project, Classroom Quizshow (
www.classroomquizshow.com), using HyperCard during spring break of my first year as a fourth grade teacher back in '94. Now I'm the instructional technology specialist for my elementary school and am doing this project so hopefully my school and maybe other schools in my district can stop using a commercial product for checking in visitors that's been a bug-ridden pile of garbage for years.