No, we just name the printers what we need 'em to be named (you can change their names when you hook 'em up to a computer, and when you network to 'em as well) then set the appropriate printer-name in the .xml configuration file for the Flex program... I suppose I could write something that would return a list of all the printers it can find, but since each show is set up uniquely, it's just easier to name the printer(s) something appropriate when we set up the on-site equipment for the show.
But the module thing you wrote is working out incredibly well. I only had to make the most minor changes to make it work for us. The Flex program loads the AIR program which, in turn, loads the module that actually reads the appropriate data and formats the badge for printing. Then the module sends the data back to the AIR program to send to the printer(s). You just have to send the AIR program a command through a LocalConnection, and a small amount of data (the Reg ID#, Attendee #, what info to print -- i.e. the whole badge or just the event tickets, and the ArrayCollection that contains the list of printer-names and which reg-codes go to which printer) and the module takes care of the rest. Each module is custom-written for each client's show, so we can make any changes they want without affecting the other clients' shows... The Flex program communicates with the AIR program; the AIR program (minimized, running in the background) uses its loaded module to format the badge(s) then it communicates with the printer(s) directly, and there are no dialogue boxes to deal with at all... Totally feels like a hack when you look at all the programs and modules communicating back and forth, but it's working perfectly. Does exactly what my bosses wanted it to do. Thanks so much for your help! L. On Wed, Dec 15, 2010 at 11:51 AM, Eric DeCoff <[email protected]> wrote: > Hey dude > > Just wondering how the print logic going for you... > > Did you write a routine to discover local printers and name them for the > environment... I.e. HP laser = red badges > > sent via droid > On Aug 31, 2010 4:48 PM, "Laurence MacNeill" <[email protected]> > wrote: > > I could really use some major advice here. We're so close to the > finishing > > point on this project, and we're being held back by stupid printing > > problems... > > > > We *HAVE* to be able to print with no pop-up dialog boxes. None. Period. > > > > To make matters more complicated, the choice of which printer to send the > > job to will be affected by the data (i.e. a client with reg-code X gets > > printed on printer-1 and a client with reg-code Y gets printed on > printer-2 > > -- stuff like that.) So the program will somehow have to know what > > printer(s) are attached (or networked) to the machine -- it can't just > send > > all print-jobs to the default printer. > > > > We have to automate all of this, because the temp-workers we hire can't > be > > counted on to remember how do it correctly. Gotta be idiot-proof... (I > > know, every time you think you've made something idiot-proof, the > Universe > > comes up with bigger and better idiots... So let's say "mostly" idiot > > proof.) > > > > So... Any ideas on how I can deal with this? Should I dump Flash Player > and > > switch to AIR? That would that give me better control over the printing, > > yes? But, can AIR actually do all that I'm asking for here? > > > > And, if we do switch to AIR, what will that mean for accessing our data > from > > our ColdFusion/SQL server through https:, if anything? Any other pitfalls > > you can think of when migrating from Flash Player to AIR? Is there > actually > > a way to do this from the Flash Player, and maybe I won't need to deal > with > > AIR at all? > > > > Sorry about all the questions, but we're really stuck here, and I've got > to > > find a way to do this... > > > > Thanks, > > Laurence MacNeill > > Mableton, Georgia, USA >
