PARTY TIME!!!1!1!oneone
Yeah, you heard me right! We have officially entered the thought-to-be-mythical land of Beta! This comes after an all-day marathon coding session in which I completed all three remaining items on the Beta List. Of course, in doing so I created or discovered a variety of bugs. Fortunately, Matt informs me that most of them are already fixed in his working copy. He’s hoping to finish that tonight or early tomorrow so we can include those changes and bugfixes in our first official beta build. Yes, I am going to bold every instance of the word beta in this post because I am just that psyched right now!
Of course, there are still issues to be dealt with. Besides the aforementioned bugs, there are still some bugs in our tracker that need to be taken care of. The Filter bug in particular is a nasty one and it impacts critical functionality, so my top priority now is squashing that critter. There’s no way a fix for that bug will make it into tomorrow’s build though because I probably won’t have any more time to work on this until Saturday. As it is, I already broke the 10PM Rule today (only by about 20 minutes though, so I guess it isn’t that bad).
Also, I feel a need to correct a misstatement I made last week. I said that there was no way to compare two objects based on the values of certain properties without writing your own loops and sprinkling them all over your code. That’s actually not true: there are some findX methods that do this. It still doesn’t change the fact, though, that you have to build the necessary input every time, which is still annoying.
And to make up for that, I have a new epic fail to report. I changed a function so that, depending on a certain condition, one of two SOAP operations would be called. The two code paths are mutually exclusive. Despite this, MXMLC still throws an error about duplicate variable definitions. So I added a “2″ to the variables in the else clause. Not hard to work around, I’ll grant you, but still damn annoying.
Also I should report YAAEF that Matt and I have been dealing with, but I kept forgetting to post about. If you use only static methods of a class in your <Script> blocks, Adobe’s import organizer helpfully decides that you aren’t using that class and removes the import! I’ve gotten burned by this dozens of times now, when I edit an MXML file, change something that triggers the import organizer to run, then had the build fail because the organizer decided to make things too neat and removed an import that is actually necessary. D’oh!
Anyhow, that’s all from me for this week, folks! Check back over the weekend and next week as Matt and I look to quash any bugs we missed, finish re-styling the GUI, and write the IQP report.
Pingback: Flex Sucks: Greatest Hits! « CaptainRichard's Blog