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
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:
at flash.display::DisplayObjectContainer/getChildAt()
at mx.core::Container/getChildAt()[C:\dev\GMC\sdk\frameworks\mx\core\Container.as:2384]
at mx.containers.utilityClasses::BoxLayout/measure()[C:\dev\GMC\sdk\frameworks\mx\containers\utilityClasses\BoxLayout.as:88]
at mx.containers::Box/mx.containers:Box::measure()[C:\dev\GMC\sdk\frameworks\mx\containers\Box.as:250]
at mx.core::UIComponent/mx.core:UIComponent::measureSizes()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:5360]
at mx.core::UIComponent/validateSize()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:5306]
at mx.core::Container/validateSize()[C:\dev\GMC\sdk\frameworks\mx\core\Container.as:2713]
at mx.managers::LayoutManager/mx.managers:LayoutManager::validateSize()[C:\dev\GMC\sdk\frameworks\mx\managers\LayoutManager.as:554]
at mx.managers::LayoutManager/mx.managers:LayoutManager::doPhasedInstantiation()[C:\dev\GMC\sdk\frameworks\mx\managers\LayoutManager.as:661]
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/mx.core:UIComponent::callLaterDispatcher2()[C:\dev\GMC\sdk\frameworks\mx\core\UIComponent.as:7789]
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.
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
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.
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 ;-)
http://blog.jasonnussbaum.com/?p=237
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.
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 ;-)
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...
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
shift-f2 opens the documentation for that class.
f3 takes you to the class.
best,
Seth
http://www.adobe.com/devnet/flex/quickstart/buildi...
<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 :-)
You are drawing a huge background (3500x3500) and fill it with repeated tile images, I'm not sure will this cause efficiency problems though.
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?
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...
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