In Flex 2.0.1, the Flex Panel used the HaloBorder class as its default skin. I’ve seen most custom skins for Panel that have extended either the Border or RectangularBorder class. While this worked in Flex 2.0.1, when you try to use these custom skins in Flex 3, you are just going to get one big mess. The reason for this was because the Panel now uses a new class called “PanelSkin” which is a part of the mx.halo package. This PanelSkin class extends HaloBorder and includes all of the borderMetrics and viewMetrics logic that used to be in the Panel class. This logic figures out the header height and ControlBar height and adds it to the borderMetrics. For the majority of custom Panel skins that I’ve seen that used to extend Border or RectangularBorder, you should be able to migrate your skin to work in Flex 3 with a couple of easy steps:
1. Extend PanelSkin instead of Border or RectangularBorder
2. If your skin overrides the borderMetrics getter, you should call the super getter.
I tried this out with a Flex 2 skin provided by Andrew Trice on his blog and things seemed to work fine after these minor adjustments. Good luck with your skins!
Oftentimes, when you are keeping track of a bug and it gets fixed, you will see a comment that says something like “confirmed in build 136” or “changelist 193935”. Since the bug is marked fixed, you assume that it is fixed when you download the latest beta or one of the nightly Flex SDK builds. However, to your dismay, the bug doesn’t seem to be fixed. You wonder… am I running the right version? What version number am I running?
To be clear, there are two different version numbers to think about. There is a version number for Flex Builder (the Flex IDE), and a version for the Flex SDK (the development kit that includes the compiler). If you are tracking a FB-XXXX bug, then, you will be concerned with Flex Builder versions. If you are tracking a Flex SDK bug (SDK-XXXXX), then, you will want the Flex SDK version. Unfortunately, these version numbers don’t necessarily have much in common. In the future, I hope we can somehow relate these version numbers to each other so you can tell what SDK you have included inside your Flex Builder installation. For now, use the following tips to find the version number you are looking for.
The Flex Builder version is really easy to obtain by going to Flex Builder’s ‘Help->About Flex Builder 3’ menu item. This brings up the Flex Builder splash screen with the version at the lower right corner. For the Flex SDK, there are several ways to get the version. If you are compiling Flex applications using the free Flex SDK without Flex Builder, you can just print out the version using the mxmlc compiler. Just provide the -version argument to mxmlc to print this out:
If you are using Flex Builder, you can get the Flex SDK version by finding the flex-sdk-description.xml file that is installed with your SDK. In a Flex Builder install, you should find this file in the Flex Builder install folder/sdks/3.0.0/. The file looks something like this:
<?xml version=”1.0″?><flex-sdk-description><name>Flex Moxie M3</name><version>3.0 Moxie M3</version><build>188.8.131.52</build></flex-sdk-description>
The SDK build version here is 184.108.40.206. In our bug notes, we often shorten this to ‘version 136’ or ‘changelist 136’.
One final detail on this topic… On the Flex SDK team, we were using Perforce as our source control system and our version numbers were something like ‘191569’. We have recently made a move to Subversion, so our version numbers started at zero again, so, the most recent SDK version numbers will be much smaller like ‘209’ which is equivalent to 3.0.209.
Happy 2008 to everyone. I haven’t written much here in a while since (like many other companies), Adobe and the Flex team took some time off for the holidays.
Anyways, in the last month, Flex and AIR have released its third public beta. You can download it on http://labs.adobe.com. If you have been using Flex with AIR, you might have noticed some obvious differences in your AIR application which used the Flex DragManager. In this latest release, a change has been made where any AIR application that is parented by a <mx:WindowedApplication> tag now uses the AIR NativeDragManager instead of the Flex DragManager. If your AIR application is parented by the <mx:Application> tag, then, the Flex DragManager is still being used. The purpose for this change was to allow AIR Applications to be able to drag items in and out of AIR Windows automatically. The NativeDragManager allows this.
How do you know which DragManager you are running? The easiest way to distinguish which DragManager you are using is by looking at the default feedback cursors. For the Flex DragManager, when you were dragging an item over an area that was not a valid drop target, you would see a red circle icon with an “x” inside. When you are using the AIR DragManager and you drag an item over an invalid target, you will see an icon with a black circle and diagonal line through it.
Besides the cursors, you will notice some differences in the way that drag events are triggered. Here is a summary of the differences:
1. DragEnter fires only once for each target in AIR. In a Flex web application, the dragEnter fires multiple times over one target.
2. DragOver fires for all targets even if one is not a valid dropTarget. In a Flex web application, the dragOver fired only when you were over a target that you could drop an item on.
Another issue that I have seen come up a few times for people using the NativeDragManager in their Flex/AIR Applications is one where their use of mouseX and mouseY for a target no longer works. For example, in your dragDrop event handler, you might have had some code like:
public function doDragDrop(event:DragEvent) : void
event.dragInitiator.x = event.target.mouseX;
event.dragInitiator.y = event.target.mouseY;
This used to work with the Flex DragManager, however, the AIR NativeDragManager doesn’t seem to update your target’s mouseX and mouseY properties correctly. I’m not sure of the details as to why this difference occurs, however, according to the AIR team, this mouseX and mouseY property shouldn’t update. For the above example, you should be using the event’s localX and localY properties instead. So, the above code would be changed to:
public function doDragDrop(event:DragEvent) : void
event.dragInitiator.x = event.localX;
event.dragInitiator.y = event.localY;
This seems to work since localX and localY are updated for a dragDrop event.
Some developers have expressed wanting to use the Flex DragManager instead of the AIR NativeDragManager when using a WindowedApplication. This wasn’t possible as of the Flex 3 Beta 3 build which includes Flex SDK 189825. However, a change was made later to allow for this. The change is described in SDK bug:SDK-1 3983. In this bug, Jason Szeto has provided an example (attached to the bug) of how to use the Flex DragManager in an AIR WindowedApplication. You will only be able to use the workaround as of Flex SDK build 191577, however.