Found a gotcha this week when making AS2 style components and exporting for Flash Player 6.
The new way to include your assets in your components is to make a layer called “assets”, and then put your component’s assets on that layer, preferably on frame 2, or the farthest frame that your component will never actually reach. The old way was to put it on an assets layer, but guide it out.
However, since that new layer is not guided out, it will export with the SWF, and is now printable. If you use the print command and target your component, it will print your assets. We couldn’t figure out why when printing one of our components that it kept printing out a bunch of assets on a 2nd printed page when we assumed it would only print one page… and then I guessed right that it was printing the assets frame.
The quick fix is to click on each asset, and change it’s alpha to 0. That way, at least the printer won’t actually print anything onto the 2nd page (assuming there isn’t an automatic company letterhead attached). That way, the user/client will think it’s their st00pid printer and not blame you. Besides, they can reuse the 2nd blank page anyway, so it’s not like your wasting paper.
I’m assuming you have tighter control over the Flash Player 7 PrintJob & associated printing commands, but if your still going to 6, but using Flash MX 2004 to make AS2 components, just something to watch out for.
Jesse,
I ran into a similar issue a while ago while doing an interactive floorplan application for a client that needed to print documents to the printer based on, but not identical to what was being displayed on the screen. This was done with MX (not MX 2004) in a similar fashion to what you described with some customized components that I extended from the Macromedia ones.
Originally, the components would print out as well and you’d get the page intended for the printer, as well as copies of the interface, plus odd bits and pieces from the components’ assets. I tried tweaking the “#b” and “#p” frame names as per Macromedia’s documentation, but with only partial success. After a bit of experimentation….
My solution was to break the “print” document(s) into their own separate SWFs which were loaded into a separate, hidden movieClip. At run-time, when the user chose to print, the components’ content that needed to be printed were copied into the “print” SWF and that SWF was printed via script. As it didn’t have all the UI component cruft in it, the application printed customized sheets cleanly.
I additionally optimized it on the next revision by refactoring out the components and common elements into their own shared libraries for significantly quicker downloads on the 2nd and subsequent use (as there were a series of these).
E-mail me if you’d like the link to application.
That’s a very nice offer, dude, thank you, but she’s working now, although, I’d still dig seeing it.
Yeah, I’ve seen a CD-ROM do something similiar; and I was about to make a different “screen” that printed correctly, but just by moving the assets to frame 1 and setting their _alpha to 0, all printed great, both Mac and PC.