If you’ve ever wrestled with Flex’s printing classes, you’ll know how much of a pain they can be, especially with multipage output.

You spend hours trying to get Flex to scale things properly, and when you finally succeed, you’re left with pages with mysterious 2 pixel wide lines at the bottom or side. It turns out that Flex has a slight problem guesstimating the size of the output on the page, and accidentally leaks part of your application background onto the page.

If you’re using the default styles for your application, then there’s a simple fix for this. Before you call printJob.start(), you need to turn off the background gradient, like so:

Application.application.setStyle("backgroundGradientAlphas", [0, 0]);

Then after the print job completes (or was cancelled), turn it back on:

Application.application.setStyle("backgroundGradientAlphas", [1, 1]);

Of course, if you’re using something other than the default background, then you’ll probably need to store the old styles, turn the background off, then retrieve and re-set the old styles again.

About a month ago Dean Hachamovitch, the General Manager for Internet Explorer 8 released the news that IE8 passes the Acid2 test. In this article, we’ll be taking a look at how the current browsers stand up to the next generation of web standards with the Acid3 test.

Acid2 is a test intended to identify rendering flaws in web browsers, often raised as a result of neglecting to follow the proper standards for HTML and CSS. The Acid3 test is the successor to this, and primarily focuses on scripting and document object model handling.

It should be noted that the Acid3 is still under development, and that its author, Ian Hickson, has stated that:

The Acid3 test IS NOT READY. Goodness gracious people, it’s in the middle of being done! There are sections that are incomplete, some that are wrong, and so on! 

Despite this, I’m going to throw caution to the wind and give you an early look at some of the results. The test now gives a score out of 100, with a point being scored for every test that passes. Obviously, the results with a higher score indicate that they handle the test better. Below you can find a table with the results collected:

Of course, these results should be taken with a pinch of salt as the test is still under development, but I think one of the more interesting results is that Safari on the iPhone fares better than Safari 3 under Leopard. Does this mean that the rendering engine on the iPhone is a newer version than the main Safari browser?

I look forward to bringing you more results when the test nears completion, but if any of you would like to contribute your results for other browsers and versions, please do so in the comments and I will add them to this post.

Update: Thanks Matt for the Opera 9.50 results.

Do you have a Flex 2 or Flex 3 Beta 2 application with a SOAP based web services backend? If so, you might want to consider holding off upgrading to Flex 3 Beta 3 or the final version of Flex 3 (when it’s released).

If you do upgrade, you may notice that attributes on objects received in web service responses are not always present.

As a real world example, we were expecting to receive an object such as:

(Object)#0
isActive = false
id = 14
name = Salon7

Our server logs (and manual calling of the web service) showed that all the attributes were being sent, however, in Flex the object was received as:

(Object)#0
isActive = false


Obviously it’s not very helpful when two thirds of your object attributes go missing.

My colleague Jason filed bug #SDK-14194 over at the Flex bug tracker, and after some discussion it turns out that the way Flex handles certain SOAP elements changed between beta 2 and beta 3. Prior to beta 3, xsd:all elements (typically used in structuring complex objects, particularly those encoded by Ruby on Rails’ ActionWebService/SOAP4R), allowed child elements to appear in any order (as is valid according to the specs). However, Flex now erroneously treats xsd:all elements as xsd:sequence elements, requiring the child elements to arrive in the same sequence as they are specified in the WSDL file.

The current workaround is to ensure that you specify the element as an xsd:sequence and/or ensure that child elements arrive in the predefined order, but for those of you using third party web services or those backed by libraries/frameworks such as SOAP4R and Rails’ ActionWebService this might not be possible.

Unfortunately Svetlin Kalaydjiev of Adobe has stated that this bug won’t be fixed in time for the final Flex 3 release, but that it may be fixed some time after Flex is open sourced. I have filed enhancement request #SDK-14321 to request support for the xsd:all tag. If you are experiencing this problem it may be helpful if you provide Adobe with some input regarding your experiences.

For those of you using Rails’ ActionWebService, we have made some progress on a patch which ensures that xsd:all child elements arrive in the same order each time and will keep you posted if we produce a releasable patch.

Welcome to the new website for ActiveGuru Ltd. 

Over the coming months we will be making posts on this blog regarding software development, web development and conducting business online. 

We hope you will find the content here useful.