Episode V: PrintJob Strikes Back
How naïve it was of me to think that Flash wouldn't have an ace up its sleeve when I jubilantly announced my victory over printing a TextArea component's multi-page contents.
Truth be told, the weathered programmer, having gotten all the pages to scroll to their exact locations had thought the battle over. He had celebrated and there had been much merriment. Yet he was unaware that in Flash, What You See Is *Not* What You Print!
That was a lesson he learned later, when, after having refactored the mess that his spikes had become, he actually tried to print the resulting page clips -- those same page clips that looked so fine garbed in countless glimmering pixels on his screen. Aghast he was when he discovered that the conniving trickster who answers to the name Flash had behind the scenes and far from sight -- changed the layout of the text in his TextArea components when printing them so that the printed layouts did not match what he had on screen.
Ah, a valuable lesson this: Never underestimate Flash's ability to throw you a curve ball!
So, was this the fatal blow? Will the embattled geek rise from the ashes to wrench his ultimate prize of the perfectly printed multi-page TextArea from the wretched claws of the one they call The IDE? Only time and an ever growing pile of pulled out hair will tell!
[Update: After writing this blog post, Flash and I sat down and had a long talk and worked things out. We've decided to give each other some space and start seeing other people. I think it's all for the best. We're still living together though I think there's hope.]
Comments
It recalculates stuff when you print it out, that's for sure, there's not much to do about it. I circumvented the problem in a recent project by creating a bunch of textfields with displaced _y based on textHeight. It was for a column view of sorts. It worked out all right, but it was a pain to get working.
by Patrick Mineault on 2005-01-04 21:47:49
fwiw
g.
by gwygonik on 2005-01-04 22:09:25
And when you'll be able to print several pages (like a multiple page with a text scrolling...) you will be facing a real, big, and horrible bug: to print multiple pages, you have to write a function (of course). But, but, the PrintJob is calling another system object: the print spooler. tadaaaaa: flash is not really 'pausing' your function, so after few seconds, you'll have a wonderfull 'Flash run slowly blabla blabla' error message!
Actually, the only way to 'fix' that is to use ASV or Flasm to put the scriptlimit tag to 60 or 120 seconds (and enjoy the debugging...).
I'm looking forward, but if you find an other trick, tell us!
PS: I made a StreetMail Application in my system that print letter or fax in flash templates that output perfectly controled printouts.
by François on 2005-01-05 05:31:02
IT WORKS!!!
The darn thing works!
(I have the FlashPaper to prove it!)
Expect another post after I'm off this train and have had a bite to eat for dinner!
Thank you all again for your help!
by aral on 2005-01-05 16:40:16
Do you experience the 'timeout' problem or the material you print is not 'heavy' enough? I publish a preview of my App this afternoon:
http://www.nectil.com/Public/News.php?ID=982
by François on 2005-01-05 17:26:10
Thanks, man! Your application looks very sleek by the way.
The way I designed the print solution, it doesn't time out: The trick is to use intervals instead of a regular loop. This complicates your implementation, of course, but, since it spans multiple frames, it doesn't ever timeout.
Hope that helps and best of luck with your app!
by Aral Balkan on 2005-01-06 04:29:13
I try the intervals, but a printJob have to be in one frame (read: in the same Scope Chain) to work. With this trick, I have to setup the printer at every documents, and if my document have 3 or more pages, at every page!? Have I miss something?
Argh says the troll. I have to go back to the (uglier I agree but persuasive) scriptlimit tag hack.
by François on 2005-01-06 15:06:40
The trick is to prepare your pages *before* you start the PrintJob.
Also: I've held off on a new post because I uncovered at least one test case wherein my TextAreaDecorator fails. In fact, it's not so much the TextAreaDecorator failing but the TextArea absolutely refusing to initialize correctly regardless of how long you wait before invalidating it!
The search for the perfect solution continues...
by aral on 2005-01-06 15:13:02
by Mark on 2006-09-28 19:20:45
by aral on 2006-09-29 10:51:19
by Richard Pang on 2007-10-22 11:40:13
by Tim Harris on 2008-02-01 23:39:15
by gern on 2010-10-07 20:24:31