When variableRowHeight is set to true on AdvancedDataGrid,
(a) mx.controls.AdvancedDataGrid ignores attributes such as rowCount.
(b) there is no way to figure out the height of the AdvancedDataGrid instance because we don’t know how much height we will need to show the rows of data in our dataProvider. We can set the height to maxHeight but what of the sum of heights of all rows in our grid is less than the maxHeight, we need our grid to adjust itself to the shorter height but the AdvancedDataGrid does not.

(c) When opening/closing trees in hierarchical data inside the grid, we need the grid to automatically adjust its height. AdvancedDataGrid does not do that when variableRowHeight == true

The AutoSizingAdvancedDataGrid fixes this issues. It does this by dynamically increasing the height of the array until (a) all the rows in the dataProvider have been displayed or (b) maxHeight has been reached.

Click the image or here to see the example app.  You can right-click and view source as well.

Some of the Flex compiler warnings are more informational in nature i.e. they are not really warnings just information pointers, sort of like “are you sure this is what you want, if yes then ignore”.  I discuss two of them that directly affect many apps below –

 1.  One such so-called warning comes up when you do not specify an explicit scope for your variable or method.  For example –  

 Declaring a function as follows will give a compiler warning in flex –

public class Foo {

function bar():void {

            //whatever

}

}

The warning would read like this: “1084: function bar will be scoped to the default namespace: Foo.internal and will not be visible outside this package”.  Now this is useful information only if the developer wanted this function to be visible outside its package.  On the other hand, if the intended design was to not have this function visible outside the package, then the signature of the function is correct and specifying any of the scope keywords (public, private or protected) on this function just to get rid of the warning would be incorrect as that’s changing the design.  Package scope is common in modern object oriented languages such as Java and ActionScript 3.  Java compiler does not complain about it, AS compiler shouldn’t too.

2.  The other such warning that comes up very frequently in Flex has to do with bindings.  For example –

 Let’s say that I have a mxml component as follows:

<mx:Text text=”{label}” xmlns….>

            <mx:Script>

                        <![CDATA[

                                    public var label:String;

                        ]]>

            </mx:Script>

</mx:Text>

 Flex will give you a warning that changes to label will not be detected by data binding.  This is an issue only if the developer wants the variable to be bindable.  In many cases in an application where [Bindable] has not been specified for a variable, the developer did not want it to be bindable mostly because the variable will never change its value once it has been initialized or if the intent is that the change in value should not update the bound variable.  One way to achieve this is to manuelly update the value in AS code instead of specifying it as a bound variable in MXML.  That is not the idea case for people like myself who like the elegance of MXML and want to resist the temptation to write AS code.

We ran into this issue while debugging memory issues in our flex application. This issue has been fixed in the latest beta version of the Flash Player 9.0.60.184. Here is the issue for your reference as it might help you debug memory issues in your application, also download and run the example source to replicate it.

As I was debugging some of the memory issues we are having, I noticed that the objects of types container do not get garbage collected if they have one or more children specified as MXML tags (or alternatively added through component descriptors). I looked at the mx.core.Container class and noticed that it keeps an array called _createdComponents of all the components that were created through their descriptors. It populates that array in the createComponentsFromDescriptors method. The problem is that it never gets rid of the components in the array when they are removed by calling any of the remove methods such as removeAllchildren, removeChildAt etc. That array thus keeps a strong reference to children that had already been deleted and should have been garbage collected. This also gives rise to a circular reference case where the parent and the child both don’t get GC’d.

I have created a small program that might be helpful in reproducing this bug.

1. After you load the files into a project, run the swf
2. Click on “Create AS based child”
3. Click on “Trace Reference”, it will show you the created children
4. Click on “Remove All” and then “Force GC”
5. Click on trace reference, you will see no references
6. Click on “Create Descriptor based child”
7. Click on “Trace Reference”, it will show you the created children
8. Click on “Remove All” and then “Force GC”
9. Click on “Trace Reference”, you will notice that the reference still hangs around even after it has been deleted and GC has run

There is another memory leak that occurs when you specify verticalGap or horizontalGap attributes on any container. This issue has also been resolved in the Flash Player version specified above.

check ‘em out -

Clip 1: Intro http://www.youtube.com/watch?v=jHBwaJLhaR4

Clip 2: Global http://www.youtube.com/watch?v=9U3SsC2jqdo

Clip 3: Upgrade http://www.youtube.com/watch?v=_8-LSfNKVXw

1.  The race is on, Microsoft to open source “some” of its SilverLight technology.  Microsoft’s definition of open source is generally limited to sharing the code with developers outside the company i.e. it has never allowed outsiders to actually contribute code to its products.  If they stick to that old strategy, open source developers would just yawn at this.  Adobe, on the other hand, is planning on gradually taking more of an Apache type approach for Flex where developers outside of Adobe can fix bugs and make enhancements to the platform. In any case, this smells like the browser wars of the 90s. 

Read the full story at – http://www.techworld.com/news/index.cfm?newsID=8703&printerfriendly=1

2.  Microsoft plans on making their CLR (Common Language Runtime) available cross platform.  Essentially, both.NET and SilverLight will one day be available on platforms other than windows and in turn browsers other than IE.  This will diminish a significant competitive advantage that Adobe had with Flex.

Read the full story at – http://blogs.zdnet.com/microsoft/?p=414

How do you think the RIA market is shaping up?  Who in your opinion has a better chance at success, is it Microsoft, Adobe, AJAX or an underdog like Lazlo?  Share your insights and opinions with us.

Stay tuned for exciting news and opinions on user interface, Flex and whatever else is brewing in our heads.