Flex/Flash/Actionscript

Followup about Flex Panel bug

I want to start off with a quick recap of the current status of the bug I wrote about a few days ago. The Flex 3 Panel bug that resulted in the content of a Panel overlapping the title bar of the Panel has been fixed. The fix will be in the final Flex 3 release. The bug report that shows this status is here: Issue 11279, which is now marked as a resolved bug. I want to point out that I was told (with proof) that Adobe recently started re-investigating this bug on their own about a week before I posted my rant (although that was never exlained in the bug database).

I also want to take a second to address what was seen as me being an asshole with what Matt Chotin called my “strongly worded criticism.” 🙂 I also received another email from a Flex team member with a similar sentiment letting me know that I may have been a bit harsh and that I need to remember that the engineers working on the framework are good guys trying to do the best job they can for us (the customers). I’ve met Matt personally a few times, and I deeply respect him and all the Adobe engineers working on Flex. I didn’t mean my little rant to come off as a personal attack on anyone, although I realize that since I was targeting a very specific bug that that means it falls under the responsibility of a few individuals. My harshness was a result of frustration and a misunderstanding of Adobe’s perspective, there was never meant to be any direct blame placed on individual engineers. And so with that, here’s my olive branch:

921-i_love_you_teddy_bear.jpgDear Flex team, I love you all. Your work is greatly appreciated. You make it possible for me and many other people to do work that we love. You’ve delivered a fantastic product and the overall intelligence of the team shows through in the great code base of the Flex SDK. Keep doing your jobs. Even though I may criticize, I mean it with love and respect.

OK, everyone feeling all warm and fuzzy inside? Cool, let’s all get back to work.

Matt Chotin addresses what to do if you run into similar issues like this Panel bug, where you don’t feel the Flex team addressed the issue adequately. He mentions that you will be able to vote on closed bugs in the future, so once that is in place you can still vote on a bug even if it has been marked as NAB, and the Flex team will be able to see which ones have the most community involvement. Until then your options seem to be leaving comments on the closed bug (which in this case meant 4 or 5 independent bug reports of the same issue) and emailing the Flex team, which I think means email Matt, since I can imagine that they don’t want all the engineers dealing with trivial requests from the community all day long.

That said, I’m not sure if I had dealt with the bug differently (ie simply posted a comment and emailed Matt) that it would have gotten fixed so immediately. While I understand that internally Adobe was re-investigating this bug, my hunch is that without the public bitching there would not have been a fix committed for the final Flex 3 release (feel free to correct me if I’m wrong). A single comment on a bug report and an email to Matt likely would have gotten it on the radar (although it already was), but I’m guessing we wouldn’t have seen such immediate action. So perhaps I should have phrased my previous post in a better way, and simply called attention to the bug to try to get others to comment on it so they would reopen. But I think there is certainly a place for publicly posting issues like this, since it’s an effective way to rally the troops and clearly articulate the issue (what was I going to do, write a 2,000 word comment in the bug database?). So in the future I’ll try to be a tiny bit more diplomatic with how I write posts like that.

So thank you Adobe for the quick action in response to this issue.

Standard
Flex/Flash/Actionscript

View differences between Flex 3 Beta 2 SDK and Beta 1 SDK

UPDATE: Well shit, turns out that posting the source of the almost-open-source-but-not-quite-yet Flex SDK is a no-no for now. I assume once the Flex 3 SDK officially goes open source this will be OK, but for now I’ve been asked by Adobe to take it down. As you say master.

I’ve posted the Flex 3 Beta 2 SDK that can be compared using Trac to the previous Beta 1 SDK files. This lets you easily see what changed from Beta 1 to Beta 2.

View the changest from Beta 1 to Beta 2 here.

Check out the main Trac site here.

New files:

  • ButtonBar.png
  • mx.controls.dataGridClasses.DataGridHeaderBase
  • mx.controls.dataGridClasses.DataGridLockedRowContentHolder
  • mx.controls.menuClasses.MenuListData
  • mx.core.EmbeddedFont
  • mx.core.EmbeddedFontRegistry
  • mx.core.IConstraintClient
  • mx.core.IEmbeddedFontRegistry
  • mx.core.IFontContextComponent
  • mx.core.ITextFieldFactory
  • mx.core.TextFieldFactory
  • easing_readme.txt
  • mx.styles.IStyleManager2
  • mx.styles.StyleProxy

Some other things to note:

  • Lots of the files have a very basic change in the copyright notice: from “2003-2006 Adobe Macromedia Software LLC and its licensors” to “2003-2007 Adobe Systems Incorporated”. That unfortunately means a lot of “false positives” show up in the changeset.
  • I guess joining Adobe means Robert Penner gets to pimp his own book (even with a direct link to the page on Amazon) within the SDK source code.( 😛 I’m just busting balls)
  • There are lots of trace statements commented out, giving us an insight into the Flex team’s debugging mind. ListBase has 40 such statements that haven’t been removed from the code. DataGrid has 54. ProgressBar line 1631 has the wonderful “Move indeterminate” trace statement.
  • There’s some new stuff for styling. It looks like they’ve added a class called StyleProxy (note: at the moment completely undocumented and has large blocks of commented-out code), and that you can use that to set the default styles on custom components. I don’t really know much about this (Juan, want to chime in?) but check out the changes in TabNavigator to see a little how they’re using StyleProxy.
Standard
Flex/Flash/Actionscript

Move indeterminate

Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate
Move indeterminate

A little jab at the Flex 3 SDK team. This is about a bug in the Flex 2 Beta 2 release. Looks like someone forgot to remove a trace statement. Woops.

If you want to get overwhelmed with “Move indeterminate” trace statements then debug this app in the latest Flex Builder:





 

This bug has been fixed, although not scheduled to be rolled out until next beta. I assume you can grab a nightly build and install a newer version of the SDK if you want to make these trace statements go away.

I’ll be bitching more fairly soon about some other pain points when upgrading an app from Flex 3 Beta 1 to Flex 3 Beta 2.

Standard