Skip navigation
Chris Pamplin
Currently Being Moderated

Printing from a component

Nov 16, 2012 6:52 AM

Tags: #print #flash_builder_4.6 #addelement

In the Flash user guide there is an example of how to print using a custom control to deal with the layout for printing. In the code example it has the following code snippet:

 

public function doPrint():void {

     // Create a FlexPrintJob instance.

     var printJob:FlexPrintJob = new FlexPrintJob();

     // Start the print job.

     if(printJob.start()) {

          // Create a MyPrintView control as a child

          // of the current view.

          var formPrintView:MyPrintView = new MyPrintView();

          addElement(formPrintView);

          ...

 

The problem I have is that the call to addElement is flagged as a problem (may be undefined) in the code editor and fails with an error (ArgumentError: espMain18.WindowedApplicationSkin19.Group20.contentGroup.PrintRendere d1039 is not found in this Group) when I run the application and try to print.

 

I can get around this by adding FlexGlobals.TopLevelApplication. before the call to addElement, but that results in all print out having a gray tint across the whole page.

 

If, instead, I add a try catch block around the addElement call and simply ignore the error, the print comes out as intended without the gray tint overlaying everything.

 

What am I doing wrong? How am I suppsoed to use the addElement call?

 

Chris

 
Replies
  • Currently Being Moderated
    Nov 29, 2012 2:44 PM   in reply to Chris Pamplin

    Well, nothing much can go wrong with a call to addElement, provided:

    a) You make the call on a class that _has_ the addElement method

    b) You call it with something that is a valid IVisualElement

     

    For b), you say that the call works when you use FlexGlobals.topLevelApplication.addElement(); so (although you haven't provided source) I can be confident that MyPrintView is a valid IVisualElement. So b) is not the problem. Calling FlexGlobals.topLevelApplication.addElement(); works because the application is an IVisualElementContainer and so has the addElement method defined.

     

    Therefore, I conclude that you have defined this method on something other than the display class that you are printing.

     

    You have either defined the method on a class that is not an IVisualElementContainer (for example, did you build this as an extension of Sprite, outside of Flex? or did you create a separate print manager class?) or created an anonymous function within the display class that cannot resolve "this" to the container.

     

    So...

     

    Check where and what you have set your print job method up on. If you are using Flex, then it can just be a method of the containing s:Group or s:View or whatever. If it is a Sprite in a pure Flash app, then you can replace addElement with addChild instead.

     

    G

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 30, 2012 9:54 AM   in reply to Chris Pamplin

    Separating out logical code from display code is nothing to be ashamed of, but there are better ways of doing it... Remember, you are in an OOP environment, so you can organise things to share functionality across a wide range of things without getting tied up in global function hell.

     

    For example, I could do this:

    [code]

    package com.whatever

    {

      import spark.components.Group;

     

    [Event(name="customEvent",type="flash.events.Event")]

    public class PGroupBase extends Group

    [/code]

     

    I can then add custom properties to that class, or create subclasses of that class, or quite a lot of other things. I can implement interfaces and I can use static properties to provide global links between every instance and so on and so forth.

     

    And, from a design perspective, in my display code, I still end up with the very simple and familiar:

     

    [code]

    <whatever:PGroupBase width="100%" height="100%"

        customEvent="doSomethingOnACustomEvent(event)"

        />

    [/code]

     

    That doesn't stop you from separating out purely abstract code into purely abstract classes - for example, I have a singleton pattern OrientationManager class that provides me with full control over stage rotation etc for anything that cares to use it in just a couple of lines - but it does mean that you can leverage the full might of Flex IVisualElement and IUIComponent power without tieing yourself up in knots.

    G

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points