TheRealTimeWeb.com: Flex seems a bit broken

Flex seems a bit broken

Posted by Stefan Richter in Flex | 19 Comments

Sounds harsh I know - and don't get me wrong, I love Flex and I'm finding myself developing in AS3 more and more every day. Yet it seems seriously broken at times and I have to put up fights with problems that shouldn't cost me hours upon hours to figure out. I'm not sure if these are Flexbuilder bugs or problems with the framework (bit of both I think) but they are definitely in the way. Rapid Application Development? Not for me, sorry. Applications yes, development yes, but rapid? Nope.
And I can back it up. For starters Flexbuilder seems slow. It's a bad sign when my two fingered coding technique outruns the editor I am working in. Flexbuilder seems to have to play catch up at times, too often for my liking. So no rapidness here.

Then there are the actual bugs in my code - or is it me? How can it be that my app only runs without errors after adding a rightAlign label property to a RadioButton? RightAling out - app throws a runtime error. RighAlign back in - all is fine.
And just now (the reason I write this post) I was working on another FMS chat app with 3 states. I can go ok from state 1 to state 2. But from state 2 to 3 only works if I don't add a width to a specific custom MXML component. Granted, maybe I am too much of a noob and I don't realise what I am doing but why would a width of 160 run fine on this (Simple) component but a width of 180 throw a runtime error? And what's more, the error is not pointing to anything in my code...
It's a fairly complex app which connects to FMS2, sends video, audio, uses bindings, custom renderers, custom AS and MXML components and all works fine, except this throws a runtime error when being added via :

view plain print about

1<FCG:UserAVList width="180" id="userlist" height="100%" itemRenderer="usersRenderer" dataProvider="{chat.dpUsers}"> </FCG:UserAVList>

As soon as I change the width to 160 (as in FCG:UserAVList width="160"...) it works fine again. Huh? And before you ask, I've reset pretty much every width setting both inside and outside of this component with no effect.
So I manage to build an app that connects to FMS but setting a width throws me off course... brilliant. I spent 2 hours trying to figure this one out, yet so far no joy. The error I see is this:

view plain print about

1RangeError: Error #2006: The supplied index is out of bounds.
2    at flash.display::DisplayObjectContainer/getChildAt()
3    at mx.core::Container/getChildAt()[C:\dev\GMC\sdk\frameworks\mx\core\Container.as:2384]
4    at mx.containers.utilityClasses::BoxLayout/measure()[C:\dev\GMC\sdk\frameworks\mx\containers\utilityClasses\BoxLayout.as:88]
5    at mx.containers::Box/mx.containers:Box::measure()[C:\dev\GMC\sdk\frameworks\mx\containers\Box.as:250]
6    at mx.core::UIComponent/mx.core:UIComponent::measureSizes()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:5360]
7    at mx.core::UIComponent/validateSize()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:5306]
8    at mx.core::Container/validateSize()[C:\dev\GMC\sdk\frameworks\mx\core\Container.as:2713]
9    at mx.managers::LayoutManager/mx.managers:LayoutManager::validateSize()[C:\dev\GMC\sdk\frameworks\mx\managers\LayoutManager.as:554]
10    at mx.managers::LayoutManager/mx.managers:LayoutManager::doPhasedInstantiation()[C:\dev\GMC\sdk\frameworks\mx\managers\LayoutManager.as:661]
11    at Function/http://adobe.com/AS3/2006/builtin::apply()
12    at mx.core::UIComponent/mx.core:UIComponent::callLaterDispatcher2()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:7789]
13    at mx.core::UIComponent/mx.core:UIComponent::callLaterDispatcher()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:7732]

Doesn't seem to make sense. A supplied index to getChildAt() is out of bounds - but only if my component's width is greater than a certain value. Hmmmm....
Even better, the Debugger tells me that there is [no source] for the line at which the error occurs. Grrrr. And all the classes listed refer to UIComponent, LayoutManager etc but not to any of my code.
I think I better go to bed, this isn't going to happen today I think...
Anyone else find Flex development quite frustrating at times? It works great when it works, but often enough it doesn't. The Radiobutton issue btw has been confirmed as a bug and been fixed internally... It wouldn't surprise me if this width issue was another one.

Tweet Follow @stefanrichter
Posted on December 4, 2006 at 10:20 PM. 17937 views. 19 comments. Print

TweetBacks

Comments

[Add Comment] [Subscribe to Comments]

#1 by Ted Patrick on 12/4/06 - 9:56 PM

Stefan,

Did you post issues to FlexCoders, Adobe Flex Forums, or open an issue with Adobe Support?

I am 99% sure that your issues are easily solved. FlexCoders or Adobe Flex Forums are there to support developers but if you struggle in silence, the community cannot possibly help you. Many of the Flex Engineers are on these lists and as a team we do whatever it takes to make a difference.

Happy to help anytime.

Regards,

Ted Patrick
Flex Evangelist
Adobe Systems
#2 by Mike Morearty on 12/4/06 - 10:02 PM

Re: the debugger telling you there is [no source] at the line where the error occurred: It does that because that function, DisplayObjectContainer.getChildAt(), is a native (C++) function inside the Player itself. Even if you could see that code, it wouldn't help you at all -- all it does is check if the passed-in index is in range, and throw an exception if it isn't.

So if you look at the values that are one level farther down on the stack -- Container.getChildAt() -- you will see the object on which getChildAt() was called, and the index that was passed to that function.

Conceptually this is the same as if you were writing a C++ app that called a native OS function, and that function threw an exception -- you can't read the source of the OS, but you can of course look at the code that called into the OS.
#3 by Stefan on 12/4/06 - 10:05 PM

Blogging here isn't silent :-)

I find posting to Flexcoders too difficult for more complex problems, it's much easier to post it here and wait for ideas to come in.
I wasn't particularly expecting a solution in this case (but I'm all ears if you have any suggestions) but was simply expressing my experiences during my first few weeks with Flex. and let me underline again: I love it and it's great, it's definitely got some teething problems which again is expected. Still it can be frustrating.

Oh and I just had another one - using an image as a tiling a background graphic. Oh joy.

Sorry if my posts are upsetting anyone ;-)
#4 by Jason Nussbaum on 12/4/06 - 10:06 PM

I don't use Flex builder personally (I'm a FlashDevelop fan), but I'm definitely with you on the API, though from a slightly different perspective...see:
http://blog.jasonnussbaum.com/?p=237
#5 by Stefan on 12/4/06 - 10:12 PM

thanks Mike - but Flex can't be serious if that's the case.
It shows me something I don't understand because otherwise it woudl have to show me stuff I wouldn't understand - great.

I also have no clue that DisplayObjectContainer.getChildAt() is a native C++ function (I have never touched C++ in my life) and even if I did know that it wouldn't help me.

I did look further down (all the way actually) and I am none the wiser. These classes are not mine so don't expect me to understand or be able to fix them. The error message did nothing for me - maybe the debugger sets its expectations too high with me.

As I said I am not so much looking for solutions here but merely pointing out some experiences - which do frustrate me.

FWIW the app works now, I simply entered some other width values and played around with those until it worked. Why a width of 200 is ok but 180 isn't is anyone's guess. I haven't got hours to spend (woops - already did) to figure this out.
#6 by Stefan on 12/4/06 - 10:18 PM

Jason, I love FlashDevelop too, haven;t used it for MXML yet though.
I'm with you on the events - on one hand they want you to use constants, on the other they let you get away with strings. Also having tons of AS code mixed within MXML still doesn't seem right to me (I am trying hard to minimize it but it's tough) - and no, includes do not count. Writing AS into MXML seems to me to be the equivalent of code on frames, and include is just that - an include. Welcome to Flash 6.

But let's leave that for another rant ;-)
#7 by creacog on 12/4/06 - 10:31 PM

"Oh and I just had another one - using an image as a tiling a background graphic. Oh joy."

two approaches :

1. Quick hack for the application background:
http://creacog.wordpress.com/2006/11/21/tile-or-re...

2. More generic/structured usable on other components - but not quite finished?:
http://ria.richtechmedia.com/2006/09/21/using-repe...
#8 by Jensa on 12/4/06 - 11:54 PM

Stefan, I'm all with you. Just went though a rough week spending far too much time debugging things that the really IDE could have told me was wrong, not just throwing pointless errors.

I'm at Flash on the Beach right now talking to fellow developers having similar frustrations and we all agree that there certainly are some issues, one of them being the fact that you actually need to learn how to use the Flex Help. It's so unusable unless you learn how to use it...

I too love Flex, but thus far it's far from rapid. I spend way too much time in the help files trying to find what I've done wrong. The answer is usually in there somewhere, I just can't "filter" which one of the maybe 200 search results that has that important info.

I'm learning but I must say that I find it a little odd that I need to learn how to use Help + the compiler could certainly need some work in terms of more understandable errors.

J
#9 by Seth on 12/5/06 - 4:23 AM

friendly tip, here's a couple flex hot keys i can't live without:

shift-f2 opens the documentation for that class.
f3 takes you to the class.

best,
Seth
#10 by Cub on 12/5/06 - 12:27 PM

Use code-behind! No code in the MXML, strictly just view stuff. Aral has a nice tute on adobe.com:
http://www.adobe.com/devnet/flex/quickstart/buildi...
#11 by Brad on 12/5/06 - 3:38 PM

Twice now I've scrapped a project I started building in Flex to build it faster in Flash. I fully agree with you on the "rapid" development. I keep trying to go into it with a positive attitude, but each time I'm left frustrated and annoyed. I have a coworker who swears by Flex but all he's doing is proof of concept stuff and dropping pretty buttons and forms on a page. He's not really getting into the guts of it like I am. The biggest pain I've found to date is manipulating data, cell and item rendering takes me way longer in Flex. I already have a lot of reusable code in Flash. The help docs are confusing (and I swear by Flash's help docs). And the IDE gets sluggish on me as well.
#12 by Stefan on 12/5/06 - 7:53 PM

@creacog: thanks for the links. That first one - 'you got to be kidding' comes to mind. The second one: yes needs work and I have come up with this based on the approach there, it seems to work for a tiled application background:

<mx:Script>
   <![CDATA[
      import mx.containers.Panel;
      import mx.core.BitmapAsset;

      [Embed(source='bg2.png')]
      public var bg:Class;

      import mx.core.UIComponent;

      private function init():void
      {
         var s:Shape = new Shape();
         var u:UIComponent = new UIComponent();
         u.addChild( s );
         this.addChild( u );

         var bd:BitmapData = new bg().bitmapData;
         s.graphics.beginBitmapFill( bd, null, true );
         s.graphics.drawRect(0,0, 3500, 3500); // huge
         s.graphics.endFill();
      }

   ]]>
</mx:Script>

@J: I hear you. The help docs- I spend 50% of my time there, and 25% of that waiting for it to load. I'm also with you on the fact that the correct info can be tricky to find.

@Cub: nice, I think this is what I need. I saw this article before but I guess it hadn't sunk in. Still this is tough stuff for Flex noobs... which I consider myself to be.

@Brad: I'm obviously not alone. Prototyping is awesome in Flex, simple apps also. More complex stuff (which I guess a FMS driven Flex app is) can be hard. I dig cellrenderers in Flex, so much better than before. It's got lots of positives but also so many hidden frustrations. I'll stick with it for a bit longer, the potential is definitely there. It's like learning flash all over - from version 4 :-)
#13 by jeremy on 12/6/06 - 3:42 AM

Stefan,

You are drawing a huge background (3500x3500) and fill it with repeated tile images, I'm not sure will this cause efficiency problems though.
#14 by Stefan on 12/6/06 - 9:23 AM

Jeremy,
agreed, this may not be ideal but it's what I came up with after 20 minutes. Repeating the image should be fine but ideally it may be better to base this on the user's screen res. Although I am not convinced that it really is a problem... anyone got thoughts on this? How else would I tile efficiently?
#15 by Andrew on 12/16/06 - 10:53 PM

I have to agree with these guys. My company built http://www.mapwing.com (build, share, and explore virtual tours) using flex and found it a great experience. Granted, it has a few bugs here and there. But, hey, for what it does, it totally blows ajax out of the water. I just works, unlike the infinite number of browser issues you run into with other platforms.
#16 by mike on 10/23/07 - 10:11 AM

hey man, I think the major problem with flex is that the developers largerly came from flash, and therefore have little understanding of core software engineering values. I did come from that background, so I can understand the program better.

When you change the size of the component, then an error is thrown, perhaps somewhere else in the code (either your code or the inherent code) there is a reference to pixels outside of the new size, or a calculation that involves the width that now yields a divide-by-zero error.

My point is that with some basic software engineering / computer science skills, you can usually trap the errors (try..catch or similar) and simply look through the call stack at the time the error occurred, and think about all the possible things that could have gone wrong.

As far as flex builder running slow, Ive never had a problem, and Ive run it on a windows 2000 old machine. Make sure that it is the only memory-intensive program running. i.e. dont run photoshop and keep the system tray to a bare minimum.

Dont knock flex until youve learned to work with it the way it was meant to. Flex is seriously not flash. It is really a lot closer to Java...
#17 by Michael Lively on 11/18/07 - 4:13 AM

Hi,
I must agree with your frustrations somewhat. But for those of us who were/are flash programmers with the rewrite of flash CS3 - I don't see much difference. It is all AS3 now, and the pain factor is pretty high - Flex or Flash.

But we are pushing forward with it. The payoffs are pretty high. For example, we now have 3D in Papervision and really cool apps are being released daily under open source.

So I guess there is no free lunch, but this one was pretty expensive (as far as the pain factor was concerned). I was floored at the rewrite of flash 8 to CS3 - it is what pushed us into using Flex.

Accept for the time line - it is all coding - Ouch! CS3 is a step down from From Flash 8 as far as usability is concerned and ease of app construction. But CS3 Flash rocks in speed! Maybe in the next version we will get the usability and ease of app construction back. But for now from flash 8 to CS3 is almost like learning a new application. So why not go to Flex - love the data transfer capabilities and e4x.

Best,
Mike
#18 by Ozgur on 4/24/08 - 9:06 PM

Flash sucks
#19 by Stefan Richter on 7/3/08 - 7:32 PM

Random Due, your comment has been removed for now. I will put it back if you have the balls to leave your name and email. Anonymous posting is fine, but not when you want to slander companies and products.