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
_______________________________________________
[email protected]
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
