Posts in Category "Flex"

Print Job in flex 2 beta 1

I had several tips for working with print job in flex 1.5 ( See Tips for using PrintingJob in flex 1.5). Now that the flex 2 beta is available to the public, I am trying to convert the examples to run with flex 2. The migration does not take a lot of work. However, there are some glitches. I am trying to document as much as I could to make the conversion easier for others. Needless to say, we are working with beta 1. Therefore, any thing can be changed in the future release. This is not intent to show how print job will work in flex 2. It is just an exercise to prepare myself for the final migration.

Before we start to talk about conversion for each example, we need to start with the general migration steps. Please see ActionScript 3 Learning Tips. For our code, the following are most important:

Declare types for all variables, parameters and return values.
For example: for (var i=0;i<pages;i++) should be for (var i:int=0;i<pages;i++)

Declarations with no access specifier now default to package internal, not public.
function doPrint(){} should be: public function doPrint(){}

Classes must be imported, even if references to the class are fully qualified.
Do not forget to do import mx.print.FlexPrintJob;

Properties are no longer bindable by default.
You must declare them to be bindable by using the [Bindable] metadata tag.

Functions must declare return types.
If a function does not return any value, declare its return type as void. Note,
although the document all indicating it should be “Void”, it must be “void” with
lower case.

The next important thing to note is that flex 2 uses FlexPrintJob instead of PrintJob class. Also, it is using addObject() instead of addPage() method.

The above mentioned items are general for all the print examples and should be modified accordingly in each file.

1. Migrating printDataGrid.mxml from flex 1.5:

In flex 1.5, we handle the multiple pages by calculating the page numbers we needed to print out all the rows in the datagrid. In flex 2, a method nextPage() in PrintDataGrid will do that for you. printDataGridsave.mxml shows how to use that in flex 2.

Note, you should call updateLayout(); before you do addObject() to update the DataGrid layout to reflect the results of this function.

2. Can not print out header/footer area.

Print out header/footer area become much easier in flex 2.0. You can create a view, and you can include your own header/footer to specify the contents of the start and the end of the output. There is a sample in the doc you can use as a template.

If you just want to print out multiple components on a page, as in example printextra.mxml, you will need to put all the components into one container as you did in flex 1.5. However, you no longer need to set the print area explicitly.
See printextra2.mxml for example.

3. When the print area is larger than the screen, some of the content does not print out.

This is the same as it is in flex 1.5. You will need to set “clipContent=’false’ ” at the application tag (you may not have to set at the container level any more. You still need to set the application’s width/height to be large enough for the area you want to print.

4. When printing any chart, the print out always has gray background.

This is the same as it is in flex 1.5. You can either set the backgroundColor of the container that contains the chart to a color you desire, or explicitly set the fill of the chart.
Note, because the Properties are no longer bindable by default, you must declare them to be bindable by using the [Bindable] metadata tag before you define the dataProvider variable expenses: Array. See example chartprint.mxml.

Pass different dataProvider into the same ComboBox CellRenderer used in multiple columns of a DataGrid

Recently, I got a request to provide a sample to pass different dataProvider to the same CellRenderer used in multiple columns of a DataGrid. i.e., there are multiple columns in a DataGrid that need to use the same ComboBox CellRenderer. However, the dataProvider for each of the column needs to be different. Obviously, there are several ways to do this. Here I will show two of them.

1. The first approach is tightly couple the main app and the CellRenderer.
This approach requires the CellRenderer has knowledge about the parent document. It define the different dataProvider in the main app for each column CellRenderer, and then the CellRenderer will fetch dataProvider and set the dataProvider of the ComboBox in setValue() based on the column Index we get from getCellIndex().columnIndex like this:

function setValue(str:String, item:Object, sel:Boolean) : Void
{ //Get values from the dataProvider
combo._visible =(item!=undefined);
if (item!=undefined){
var ind = getCellIndex().columnIndex;
trace (“ind=”+ind);
if (ind==0) {
combo.dataProvider = parentDocument.nameDP;
} else if (ind==1){
combo.dataProvider = parentDocument.phoneTypesDP;

combo.selectedIndex = item.phoneTypes.index;
rowData = item;
See sample passDiffDP.mxml and the cellrenderer passDiffDPCell.mxml.

2. The second approach is to create a generic CellRenderer.
If you want to have a generic CellRenderer that is not tightly coupled with the parent app, then you should not set dataProvider in the CellRenderer. Instead, you should have the parent document telling the cell renderer what the data provider is for a given column. In this way, the combo CellRenderer class can be generic and could be used by any application.

There should be different ways to create generic CellRenderer, but extending the DataGridColumn works pretty well for me.
The only thing that’s needed in the extended class is a dataProvider String. The code is as simple as the following:

class myDataGridColumn extends mx.controls.gridclasses.DataGridColumn
var dataProvider:String;

Now the new DataGridColumn will take a property dataProvider, so you can pass individual dataProvider to each column like this:
<myDataGridColumn dataProvider=”nameDP” columnName=”name” headerText=”Name” cellRenderer=”{passDiffDPCellFromMain}” editable=”true”/>
<myDataGridColumn dataProvider=”phoneTypesDP” columnName=”phoneTypes” headerText=”Phone Type” cellRenderer=”{passDiffDPCellFromMain}” editable=”false”/>

For more details, see sample code:


Tips for using PrintingJob in flex 1.5

1. The sample from “Flex 1.0: Sample code for printing from a DataGrid” doesn’t work correctly.
That sample was written for flex 1.0. To use it in flex 1.5, Use the attached PrintDatagrid.mxml instead.

2. Can’t print out header/footer area.
Let’s say you have a DataGrid you want to print, but you also want to print out a label or a button as a header of the DataGrid. To do so, you need to do two things:
1). Put the label/button and the DataGrid into a container, like VBox or Panel; in Printjob.addPage(), you need to reference the id of that container, not the DataGrid.
2). you need to set the print area properly, for example:
you need to adjust the xMin and yMin properly to include the header area. See printextra.mxml. This sample prints a button that is outside of the Panel.

3. When the print area is larger than the screen, some of the content doesn’t print out.
This is because application is clipping its children. To avoid this problem, You can set “clipContent=’false’ ” on both the application and the box your want to print. Note, in order for this to work properly, you need to set the application’s width/height to be large enough for the area you want to print.

Let’s say you want to print a DataGrid that is 500X600, and you set
<mx:Application xmlns:mx=”” width=”100%” height=”100%” >
When the browser screen is larger than 500X600, then the print will work correctly. However, if the user resizes the screen to 400X500, and then do the print, then some portion will be clipped. To make sure the print always work correctly, you need to set the application’s width/height to be always Larger than 500X600.

4. When printing any chart, the print out always has gray background.
Charts, by default, have a transparent background with alpha = 0. They do this so they can show the background of whatever is behind them, but still catch mouse events for datatips. However, since printing doesn’t support alpha, the background is showing through as grey.
There are two ways to workaround this problem:
1). set the backgrandColor of the container that contains the chart to a color you desire.
2). explicitly set the fill of the chart like this:

<mx:ColumnChart id=”column” dataProvider=”{expenses}” >
<mx:SolidColor color=”#FFFFFF” />

Note, this approach may cause problem described in #3 above. You need to set the width and height at the app level to be big enough for your chart.