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 andthings 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 objectto 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 ofinfo 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 yourdata to astring (XML). You cannot send serialized data over an lc. If you cando that, then compose the XML and send it in chunks w an anknowledgemenr eachtime from the reciever sent over a 2nd lc. When you are out of datato 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, whichiswhat 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 thejob 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 theAIR app -- but documentation on that is pretty spotty, it seems. Andtherealso seems to be a limit on the amount of data you can pass over aLocalConnection -- 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 theprinting. A example of opening launching a AIR app from Flex can be found herehttp://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 nodocumented :) 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 yourprint 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 filefrom<mx:Application> to<mx:WindowedApplication>; do a diff on the "."files inthe project folder (compare to a generic Air app), 'cause there areafewchanges.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 mostcases... In fact, I generally find that they break more than they fix... So, I guess I'm asking for your experiences with this wizard, ifyouhave 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 andwhatnot, it seems almost certain that we're going to have to switch toAIR...Has anyone here ever taken a fairly mature app from Flash Playerto AIR? I'm certain it can't be as simple as checking the "AIR App" button inthe FB4 Project Properties window -- there must be somethingelse(or manythings) that I'm going to have to change/adjust/re-write... Theappcurrently interacts a great deal with our CF server, and I'dimagine that'sgoing to have to change somehow, yes? User authentication wouldprobablyhave to change as well, I would assume?Can anyone offer any advice along these lines? If anyone here haseverdone what I'm thinking about doing, please let me know aboutyourexperiences.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 -------------------------------------------------------------
