2) We cannot centralize printing, unfortunately... There are some shows where the server is not local, ergo, we must attach the printers to the client terminals...
3) Temps can be trained, sure. They could learn, perhaps, which printer to send the job to. But they are human, after all, and humans can be counted on to make mistakes at the worst possible time. Imagine sending a print-job of 1,000 badges to the wrong printer? All that stock wasted? All that time wasted? The possibility of it happening because of a human error is just not acceptable, unfortunately... Also, there are a few shows where the attendees themselves are required to print their own badges -- they definitely aren't going to be trained properly. :-) So figuring out how to automate printing is absolutely 100% necessary, unfortunately... So that leaves #1... Flex doesn't offer good printing options, so we have to figure out a way around them... AIR offers the best options that I've found so far... We can do everything we need to do with AIR -- I just was looking for a way to use AIR in such a manner that I didn't have to convert my entire app over to AIR and deal with version #s, signing, auto-updating, etc., etc... Once we get this "print server" AIR app written, there will be few (if any) changes to it, whereas our main app is changing all the time. Far easier to have the print-server app separate from the main Flex app, IMHO. But all of this has been discussed, ad nauseum, over the past week -- see my thread entitled "Better Control of Print Jobs." :-) L. On Wed, Sep 8, 2010 at 2:31 PM, John Mason <[email protected]> wrote: > Well, a couple of things here. You might be fighting a problem that isn't > really there or at least hasn't developed yet. In a related point, if they > can print off their local printer - there's a ton of things that can go > wrong with that approach. This sounds like more of a business level problem > you're being force to solve in the code. Sorry, but that almost never works. > > There's a few ways to handle this.. > 1) Do some type of hack. This is more than likely to have problems and it > will be directly on you to solve them each time there is an issue. In the > short, all the crap will fall on you. > 2) Centralize printing and avoid the potentially bigger problem that can > come up with local printing. I tend to think this is a reasonable solution. > This, I think, will be your best option. > 3) Train the temps. This may sound silly, but if they are smart enough to > type and answer a phone, then it's reasonable to have them be able to print > to the correct printer. May not be likely, but I think it's worth a try to > avoid option 1. > > Just my 2 cents, > > John > [email protected] > > > > On 9/8/10 2:21 PM, Laurence MacNeill wrote: > >> We need the program to decide which printer the output goes to, based on >> the >> information in the database. The temp-workers we hire aren't smart enough >> to do this properly every time -- it must be automated. Pop-ups give them >> the chance to mess things up. >> >> L. >> >> On Wed, Sep 8, 2010 at 2:19 PM, John Mason<[email protected]> wrote: >> >> Interesting. What is the problem again with using pop-ups? >>> >>> John >>> >>> >>> >>> >>> On 9/8/10 1:57 PM, Laurence MacNeill wrote: >>> >>> No, unfortunately there are occasions where it does need to go to >>>> client-side printers... >>>> >>>> L. >>>> >>>> On Wed, Sep 8, 2010 at 1:53 PM, John Mason<[email protected]> >>>> wrote: >>>> >>>> Everytime I look back on this thread I see more layers added in and >>>> >>>>> things >>>>> getting more complex. We're just making this app extremely fragile and >>>>> difficult to maintain. >>>>> >>>>> So looking back at things. Correct me if I'm wrong. You have a Flex or >>>>> Air >>>>> app which has to do a print operation (with no pop ups) to 1 or 2 >>>>> prints >>>>> depending on the item being printed. I'm assuming the printing is >>>>> centralize >>>>> in the office and these print jobs aren't going off to external (client >>>>> side) printers. >>>>> >>>>> Since the printers are centralize, then the server processing the print >>>>> job >>>>> can also be centralize. Have a simple CF component using the cfprint >>>>> tag >>>>> to >>>>> direct print jobs to either of the printers. In the cfc you can also >>>>> build >>>>> out the pdf to be printed. Then simply have your Flex or AIR ping the >>>>> CFC >>>>> when it needs an item printed. >>>>> >>>>> John >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 9/8/10 1:13 PM, Laurence MacNeill wrote: >>>>> >>>>> To do that, I'd have to move the code that builds the FlexPrintJob >>>>> object >>>>> >>>>>> to >>>>>> the AIR app... Kinda wanted it to stay in the Flex app... But >>>>>> perhaps >>>>>> it'll just have to be a part of the AIR app, then... >>>>>> >>>>>> Or, if I were choose the serialization option -- I have no idea how I >>>>>> would >>>>>> go about serializing a FlexPrintJob object... LOL Is it possible to >>>>>> save >>>>>> an object to a file and pass the file's URL to the AIR app? Maybe >>>>>> that'd >>>>>> work? How does one serialize an object, anyway? >>>>>> >>>>>> Thought it was gonna be so easy -- just build the FlexPrintJob like >>>>>> I'm >>>>>> doing it now, and pass it to the AIR app... But I guess it's not >>>>>> going >>>>>> to >>>>>> be quite as easy as I first thought. >>>>>> >>>>>> L. >>>>>> On Wed, Sep 8, 2010 at 1:05 PM, Douglas Knudsen< >>>>>> [email protected] >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> you can send some info. I'd expect the AIR app to except a couple >>>>>> bits >>>>>> of >>>>>> >>>>>> info to build your FlexPrintObject. Another option, and wow we keep >>>>>>> adding >>>>>>> layers to this, is to have the Flex app send the serialized >>>>>>> FlexPrintObject >>>>>>> to the server, retrieve a GUID of sorts for it, pass this GUID to >>>>>>> AIR, >>>>>>> then >>>>>>> have AIR retrieve and de-serialize. >>>>>>> >>>>>>> Douglas Knudsen >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sep 8, 2010, at 12:25 PM, Laurence MacNeill wrote: >>>>>>> >>>>>>> Which means I can't have the Flex app launch the AIR app... :-( >>>>>>> >>>>>>> L. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 8, 2010 at 12:24 PM, Scott Talsma<[email protected] >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> You can pass variables if the Flex app is a child of the Air app. >>>>>>> >>>>>>> On Tue, Sep 7, 2010 at 8:04 PM, Laurence MacNeill< >>>>>>>> [email protected] >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> So I cannot send a FlexPrintObject over an L.C., is what you're >>>>>>>>> saying? >>>>>>>>> Hmmmm... Is there a way to send a FlexPrintJob object directly >>>>>>>>> from >>>>>>>>> the >>>>>>>>> Flex app to the AIR app? >>>>>>>>> >>>>>>>>> On Sep 7, 2010 7:15 PM, "Scott Talsma"<[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> The local connention idea will only work if you can serialize your >>>>>>>>> >>>>>>>>>> data >>>>>>>>>> >>>>>>>>>> to a >>>>>>>>>> >>>>>>>>> string (XML). You cannot send serialized data over an lc. If you >>>>>>>>> can >>>>>>>>> >>>>>>>>>> do >>>>>>>>>> that, then compose the XML and send it in chunks w an >>>>>>>>>> anknowledgemenr >>>>>>>>>> >>>>>>>>>> each >>>>>>>>>> >>>>>>>>> time from the reciever sent over a 2nd lc. When you are out of data >>>>>>>>> >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> send, >>>>>>>>>> >>>>>>>>> the flex app calls a secondary fn that starts tearing down the 2 >>>>>>>>> LCs. >>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On Sep 7, 2010, at 6:47 PM, Laurence MacNeill< >>>>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> The launching of the AIR app from the Flex app sounds like a >>>>>>>>>> better >>>>>>>>>> >>>>>>>>>> idea, >>>>>>>>>> >>>>>>>>> actually... Then the Flex app has the control over the AIR app, >>>>>>>>> which >>>>>>>>> >>>>>>>>>> is >>>>>>>>>> >>>>>>>>> what I want, it would seem... >>>>>>>>> >>>>>>>>>> I'm thinking the AIR app would be just a simple thing, taking the >>>>>>>>>> FlexPrintJob object and a printer-name of some sort, and just >>>>>>>>>> sending >>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>> job straight to that printer... >>>>>>>>> >>>>>>>>>> So, once the AIR app is open, Flex wouldn't need to open it again, >>>>>>>>>> obviously. It would seem that I would need to make a >>>>>>>>>> LocalConnection >>>>>>>>>> to >>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>> AIR app -- but documentation on that is pretty spotty, it seems. >>>>>>>>> And >>>>>>>>> >>>>>>>>>> there >>>>>>>>>> >>>>>>>>> also seems to be a limit on the amount of data you can pass over a >>>>>>>>> >>>>>>>>>> LocalConnection -- 40KB, I think? How do I pass a large >>>>>>>>>> FlexPrintJob >>>>>>>>>> through that, with that kind of limit on it? >>>>>>>>>> >>>>>>>>>> Any ideas or suggestions? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> L. >>>>>>>>>> >>>>>>>>>> On Mon, Sep 6, 2010 at 10:18 PM, Douglas Knudsen >>>>>>>>>> <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>> Yet another possibility is to create a Air based app for the >>>>>>>>>> printing >>>>>>>>>> and >>>>>>>>>> have the Flex application open it, passing needed data to it for >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> printing. >>>>>>>>>>> >>>>>>>>>>> A example of opening launching a AIR app from Flex can be found >>>>>>>>>>> here >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> http://www.medoix.com.au/2009/11/06/install-launch-air-application-from-flex-web-page/ >>>>>>>>> >>>>>>>>> Note there is a way to do this without the Adobe air.swf, but its >>>>>>>>> no >>>>>>>>> >>>>>>>>>> documented :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Douglas Knudsen >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sep 6, 2010, at 4:53 PM, Scott Talsma wrote: >>>>>>>>>>> >>>>>>>>>>> Another approach would be to create an AIR wrapper that >>>>>>>>>>> encapsulates >>>>>>>>>>> >>>>>>>>>>> your >>>>>>>>>>> >>>>>>>>>> print functionality. The AIR wrapper then loads the Flex app >>>>>>>>>> >>>>>>>>>> (mx:Application). You simply put together what you want to have >>>>>>>>>>> >>>>>>>>>>> printed >>>>>>>>>>> >>>>>>>>>> (FlexPrintJob) and then pass the instance up the parent chain. >>>>>>>>>> That >>>>>>>>>> way you >>>>>>>>>> can continue to maintain your Flex app as you are currently while >>>>>>>>>> slowly >>>>>>>>>> getting your feet wet in the AIR world w/o committing the entire >>>>>>>>>> application >>>>>>>>>> to AIR. (Additionally, you can continue to host the Flex portion >>>>>>>>>> online for >>>>>>>>>> update purposes; you just point the AIR "print client" at its >>>>>>>>>> URL.) >>>>>>>>>> >>>>>>>>>> On Mon, Sep 6, 2010 at 4:10 AM, Darin Kohles<[email protected]> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>> As (now) a desktop app. vs a web served swf: >>>>>>>>>> >>>>>>>>>> If you want to do it by hand, you'll have to change the main file >>>>>>>>>>> >>>>>>>>>>>> from >>>>>>>>>>>> >>>>>>>>>>> <mx:Application> to<mx:WindowedApplication>; do a diff on the >>>>>>>>>> "." >>>>>>>>>> >>>>>>>>>> files in >>>>>>>>>>> >>>>>>>>>>> the project folder (compare to a generic Air app), 'cause there >>>>>>>>>> are >>>>>>>>>> >>>>>>>>>> a >>>>>>>>>>> >>>>>>>>>>>> few >>>>>>>>>>>> >>>>>>>>>>> changes. >>>>>>>>>> >>>>>>>>>> If you want to add network sensitivity there is a bit more coding, >>>>>>>>>>> >>>>>>>>>>>> otherwise have your "not connected"/"fault" errors handled >>>>>>>>>>>> >>>>>>>>>>>> appropriately. >>>>>>>>>>>> That's about it! ... of course there is digital signing, update >>>>>>>>>>>> >>>>>>>>>>>> awareness, >>>>>>>>>>>> >>>>>>>>>>> @etc;. >>>>>>>>>> >>>>>>>>>> On Sat, Sep 4, 2010 at 2:39 PM, Laurence MacNeill< >>>>>>>>>>>> >>>>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> To clarify, I'm aware that FB4 has a "convert from Flash to AIR" >>>>>>>>>>> >>>>>>>>>>>> wizard... I don't trust wizards to actually do the right thing, >>>>>>>>>>>>> in >>>>>>>>>>>>> >>>>>>>>>>>>> most >>>>>>>>>>>>> >>>>>>>>>>>> cases... In fact, I generally find that they break more than >>>>>>>>>>> they >>>>>>>>>>> fix... >>>>>>>>>>> So, I guess I'm asking for your experiences with this wizard, if >>>>>>>>>>> >>>>>>>>>> you >>>>>>>>>> >>>>>>>>>> have >>>>>>>>>>> any... >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>>> L. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Sep 4, 2010 at 5:31 PM, Laurence MacNeill< >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> So... With all this discussion of printing from Flash Player >>>>>>>>>>>>> and >>>>>>>>>>>>> >>>>>>>>>>>>> whatnot, it seems almost certain that we're going to have to >>>>>>>>>>>>>> switch >>>>>>>>>>>>>> >>>>>>>>>>>>>> to >>>>>>>>>>>>>> >>>>>>>>>>>>> AIR... >>>>>>>>>>>> >>>>>>>>>>> Has anyone here ever taken a fairly mature app from Flash Player >>>>>>>>>>> >>>>>>>>>>>> to >>>>>>>>>>>>>> AIR? I'm certain it can't be as simple as checking the "AIR >>>>>>>>>>>>>> App" >>>>>>>>>>>>>> >>>>>>>>>>>>>> button in >>>>>>>>>>>>>> >>>>>>>>>>>>> the FB4 Project Properties window -- there must be something >>>>>>>>>>>> >>>>>>>>>>> else >>>>>>>>>> >>>>>>>>>> (or many >>>>>>>>>>> >>>>>>>>>>>> things) that I'm going to have to change/adjust/re-write... >>>>>>>>>>>> The >>>>>>>>>>>> >>>>>>>>>>> app >>>>>>>>>> >>>>>>>>>> currently interacts a great deal with our CF server, and I'd >>>>>>>>>>> >>>>>>>>>>>> imagine that's >>>>>>>>>>>>>> >>>>>>>>>>>>> going to have to change somehow, yes? User authentication >>>>>>>>>>>> would >>>>>>>>>>>> >>>>>>>>>>> probably >>>>>>>>>>> >>>>>>>>>>>> have to change as well, I would assume? >>>>>>>>>>>> >>>>>>>>>>> Can anyone offer any advice along these lines? If anyone here >>>>>>>>>>> has >>>>>>>>>>> >>>>>>>>>>>> ever >>>>>>>>>>>>>> >>>>>>>>>>>>> done what I'm thinking about doing, please let me know about >>>>>>>>>>>> >>>>>>>>>>> your >>>>>>>>>> >>>>>>>>>> experiences. >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Laurence MacNeill >>>>>>>>>>>>>> Mableton, Georgia, USA >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>> Darin Kohles >>>>>>>>>>>> Adobe Certified Developer >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>> Scott Talsma >>>>>>>>>>> CTO, echoEleven >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> Scott Talsma >>>>>>>> CTO, echoEleven >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------- >>>>> To unsubscribe from this list, simply email the list with unsubscribe >>>>> in >>>>> the subject line >>>>> >>>>> For more info, see http://www.affug.com >>>>> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >>>>> List hosted by http://www.fusionlink.com >>>>> ------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>> ------------------------------------------------------------- >>> To unsubscribe from this list, simply email the list with unsubscribe in >>> the subject line >>> >>> For more info, see http://www.affug.com >>> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >>> List hosted by http://www.fusionlink.com >>> ------------------------------------------------------------- >>> >>> >>> >>> > > > ------------------------------------------------------------- > To unsubscribe from this list, simply email the list with unsubscribe in > the subject line > > For more info, see http://www.affug.com > Archive @ http://www.mail-archive.com/discussion%40affug.com/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > >
