Posts in Category "Uncategorized"

Spark Checkbox DataGrid With Drag and Drop Support

The Spark DataGrid is almost ready to ship. We ran out of time to do some of the things MX DataGrid could do, including popular things like drag and drop of columns to change the order of the columns, and drag and drop of items to copy or move items to and from other DataGrids and Lists or within the same DataGrid.

I found some time to show how to add that to the DataGrid. I was able to do it without subclassing, which indicates that we got the public APIs right, but if you want to have multiple DataGrids in your app, I would fold the drag/drop code into a subclass anyway. In the demo, there is an empty list below the DataGrid you can drag to or drop from.

If you’re wondering why we couldn’t bake this into DataGrid even though I had time to code it up on my blog, it is because of the time required to test and debug and handle drag/drop of cell selection. It is a prototype, not finished code. But I’ll bet we’ll integrate code like this into a future release.

I also created the Spark version of the CheckBox in MX DataGrid post. I like this implementation of using CheckBoxes in DataGrid when the dataProvider doesn’t have a slot to store the selected state. You can use the selectedIndices or selectedItems to access which items are checked without having to loop through your dataProvider. In creating this post, I also created the Spark version of the tri-state CheckBox (a CheckBox with a partially filled check box that indicates that not all items are selected in the DataGrid. It was pretty easy to do because the skin parts are easily accessible and it is easy to add a new state to the CheckBox.

Usual caveats apply: not officially supported, may not fix bugs, etc.

Run Demo
Download Source

Flex and ScaleMode

Flex’s underlying Flash Player has various ScaleModes that dictate how the screen should respond when the Flash ‘window’ is resized. By default, Flex apps use the NO_SCALE, which means that the screen area gets larger or smaller and can clip off the right and bottom of the screen. Flex will put up scrollbars in that case. It is the most common way applications respond to changes in screen size.
Every once in a while, someone wants to use one of the other ScaleModes which essentially magnify or reduce what you see in the Flash ‘window’. There is a trick to getting this to work correctly in Flex.
The problem is that the magnification is based on the ‘default’ size of the application. For Flex, the default size is based on the width and height attributes of the application tag. If none are specified, or percentages are used, the default is 500×375. If your applications visuals are different from that size, the magnification will look funny as the Flash Player will be trying to resize the upper 500×376 of your application into the current window size.
However, if you specify a width/height that just bounds your visuals, the HTML template generated by FlexBuilder will not allow resizing. What you have to do is choose the correct size for your application, and customize the HTML template. Here’s the recipe:
1) Create your app with the default scale mode.
2) Figure out how big the app is. In the example, I placed a label at 600,600, but it extends beyond that. One way is to just guess at numbers and see when there isn’t scrollbars or too much excess space. Otherwise, use the debugger or trace out positions and sizes on creationComplete.
3) Set the application’s width/height tags to those exact dimensions
4) Open the html-templates folder. Right-click the index.template Choose: Open with -> text editor
You’ll see this:

} else if (hasRequestedVersion) {
// if we’ve detected an acceptable version
// embed the Flash Content SWF when all tests are passed
“src”, “${swf}”,
“width”, “${width}”,
“height”, “${height}”,

Change the width/height tags back to use %:

} else if (hasRequestedVersion) {
// if we’ve detected an acceptable version
// embed the Flash Content SWF when all tests are passed
“src”, “${swf}”,
“width”, “100%”,
“height”, “100%”,

There are also other ${width} and ${height| tags for non-scripting browser that you can change as well.
5) Clean re-build
That should do it. As long as the application fully covers the size you specified, you should see the correct scale effect as you resize the window.
Example Source Code
Usual caveats apply.

The Future of List Classes (Tree, TileList, DataGrid, etc)

Up through Flex 2.x, the primary goal of the list classes was to be as fast as possible. Many assumptions were taken in order to squeeze better performance out of these classes. Those assumptions have the negative effect of reducing ways you can extend the components.
We’ve seen that the Flash Player 9 and the new AS3 VM is pretty fast and are looking to spend a few cycles in Moxie and future versions on generality/subclassing/extending and new features at the expense of performance. Our rationale is that many of you want to do really fancy stuff with the list classes that is really hard to do right now, and that execution and rendering speeds are sufficient today and will continue to get better and thus should absorb and negate additional computation required by being more general.
Post-Moxie, we are considering a major overhaul to the list classes and framework in general. For Moxie, we are adding some new features and new APIs. We’ve made it easy to add effects to the renderers in the List and TileList classes (not sure DataGrid effects will make the first Moxie release). Another team is building an AdvancedDataGrid complete with summary rows, column span, grouping and more. In order to do implement these new features we’ve added some new APIs to allow renderers to be created based on the data object, divided renderers into sub-containers to separate scrollable renderers from fixed ones (header, locked columns and rows do not always scroll), and exposed more of the internals of the scrolling logic.
The Moxie versions are far from general. There’ll still be private and mx_internal variables to trip over. In subsequent releases we hope to greatly improve generality and create more common subclassing patterns throughout the framework. But the main point I want to bring out right now about the Moxie versions is about backward compatibility.
We have a commitment to retain backward compatibility with the previous version of Flex (2.x). However, we do not commit to bug-for-bug behavior compatibility. If we fix a bug and you were relying on that buggy behavior, your application’s behavior may change. We promise not to remove APIs that existed in Flex 2.x, but the fuzzy area is in how those APIs should behave. In the strictest sense, those APIs should remain the same: that some input produces the same output. However, right now, because the set of changes to the list classes was so significant, we are thinking of allowing the output to change. It would take significant additional time and effort to get 100% compatibility in the API behavior and further degrade performance and increase code size. I’m telling you this now so we can gauge the impact this will have on those of you that have subclasses the List classes. If there are certain APIs that you all use, we can consider trying to make those APIs behave more like 2.x. The percentage of folks that have done significant subclassing is small and most of what you’ve done might be in the AdvancedDataGrid and/or the effects features anyway so you might be better of using the new component or features.
Following is a sample of the changes we’ve made so far. Please give us feedback as to what the impact on you will be. Note also, that if we do a major refactoring post-Moxie, that may present a whole new learning curve in order to customize the List classes.
lockedRowCount – bug fix – no longer includes the header. If you’ve set lockedRowCount in an app, you will probably need to decrease it by one.
rowCount – bug fix – no longer includes the header.
listItems – API change – no longer includes the header at row 0. No longer includes locked columns or locked rows.
listContent – API change – no longer parents renderers that represent the header, locked columns or locked rows.
makeRowsAndColumns() – API change – only draws items for listContent, so no longer draws items for all items if there are locked columns or locked rows
visibleColumns – API change – only contains the columns that are not locked
draw***() – now draws backgrounds, highlights and selections in listContent as well as the lockedColumns sub-container if it exists
itemRenderer.parent – API change – no longer guaranteed to be listContent. Can be another sub-container.
In addition, there used to be an assumption that only the set of visible item renderers were created. In Moxie, we may create more off-screen renderers in order to handle effects and column and row span. listContent used to be positioned at 0,0 in the List class and now can be moved around in order to handle span and certain effects.
In summary, your subclass is almost guaranteed to compile, but may not run correctly, and if you’ve set lockedRowCount, you may need to adjust it by one.
If we get lots of responses, I am unlikely to reply to each one, but we’ll be listening to what you have to say.