Wow, I really should break my sentences up with comma's and fullstops. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee McColl-Sylvester Sent: 29 March 2006 15:22 To: Flashcoders mailing list Subject: RE: [Flashcoders] PrintJob causes Abort Script error message.
Remember, though, that should an unforeseen cercumstance occur in your application that will otherwise throw an error will likely hang the users machine with no typical way for the user to escape except to crash the application completely... Most users don't like that too much :-P Lee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wheeler Sent: 29 March 2006 15:04 To: Flashcoders mailing list Subject: Re: [Flashcoders] PrintJob causes Abort Script error message. Steven Sacks wrote: > I have explained in detail the source of your problem. If you choose not to > take the advice given to you by coders who know more than you about the > subject at hand, then why post a question to the list? You are doing > yourself and your client a disservice with your blame Macromedia attitude > and finger pointing. > > It's not the end of the world. Your code simply does not take into account > a synchronous call. That is not PrintJob's fault. That is not the Flash > player's fault. You should fix your code now that you understand why it's > breaking. The fact is, there's a real solution to your problem. > > Whether you realize it or not, you have already admitted that it is your > code that is to blame. You have stated twice now that the application is a > real-time trading system. In all likelihood, this means you have intervals > running and all kinds of parsing and drawing going on most of the time. The > exact kind of processes that would go haywire should Flash have to make a > synchronous call with an indeterminate response time. > > PrintJob makes a synchronous call and Flash is single threaded. All your > real-time stuff is reacting to the synchronous call. When a user presses > the print button, you need to put a halt on new processes, wait for currrent > processes to complete and then start the PrintJob. If it's going to take > more than 250ms, throw up a window that says something like "Preparing to > print". Upon completion of the PrintJob, you need to resync with the server > immediately, and should probably put up a window that says something like > "Sending data to printer" until the application is all caught up. > > Your SLI injection to increase the timeout as a solution is irreponsible. > It is a heavy-handed technique fraught with potential problems far worse > than your printing one and it doesn't actually solve the problem, it just > masks it, and poorly. I wouldn't go live with that. > > "Do the right thing." - Spike Lee > > > I would suggest setting the timeout to 7200 seconds and then test it to see what happens if you leave it sitting over lunch. Please warn us when you are going to do this, since from the tone of the conversation, there is some sense that this will cause the end of civilization as we know it. I suspect that the impact will be considerably less and the users of the application may be able to deal with any repercussions by changing their reaction to a dialogue box - it should not be taken as an invitation to go for a coffee. If Macromedia feels OK about the single threading issue, we have to cut ourselves some slack about dealing with it. It certainly is a cautionary note to designers of new applications that you should consider designing in some way to easily shutdown all of the animation and communication functions while setting up a print job. The effect on a communication link of an extended timeout might be one of the problems that you encounter since the other end might decide that you have died over lunch and cut its end. If you are re-establishing the link (authorization???) on each data transfer, this may not be a problem. Ron Ron _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
