Sorry for butting into this thread, and no offense intended, but
personally I would describe this as programmer error and not a
compiler bug. You are building into MyFirstObject a dependancy on
another object without taking into account the initialized state of
the dependant object. I see two ways to correct this:
1. Check the state of the property of the dependant object when you
access it. You can do this just by seeing if the property you are
accessing has been defined, and taking appropriate action if not.
<MyFirstObject initialize="handleInit()" >
<mx:Script>
public var innerWidth: Number;
public function handleInit() {
if (myOtherObject.outerWidth != undefined) {
innerWidth=myOtherObject.otherWidth;
}
else {
doLater(this, "handleInit");
}
}
</mx:Script>
2. The second, and in my opinion better, way is to create components
and utilize binding from the parent rather than the component.
// component MyFirstObject
<MyFirstObject ... >
<mx:Script>
public var innerWidth: Number;
</mx:Script>
<mx:Image width="{innerWidth}" />
</MyFirstObject>
// component MyOtherObject
<MyOtherObject initialize="handleInit()" >
<mx:Script>
public var otherWidth: Number;
public function handleInit() {
otherWidth=55;
}
</mx:Script>
</MyOtherObject>
// application that uses the components
...
<mx:HBox>
<MyFirstObject id="myFirstObject"
innerWidth="{myOtherObject.otherWidth}" />
<MyOtherObject id="myOtherObject" />
</mx:HBox>
Either approach should take care of the initialization issues you are
seeing. If you want to provide specific sample code showing the
problem, I can try to give more details.
Hoping that helps,
Doug
--- In [email protected], G <[EMAIL PROTECTED]> wrote:
>
> If I haven't bored you yet, I would love to tell you
> exactly what the issue is. For a long time now we've
> occasionally seen very strange behavior. As I
> described before, you'll write something, get
> everything working perfectly, then do a clean build
> before deploying and suddenly something disappears.
> The problem is clearly that some properties are not
> being initialized properly. I can make it happen
> regularly and predictably right now. I do a clean
> build, and one component's x & y are not set, so they
> show up in the upper left. Then I "touch" that file
> (I put the line "if (false) true;" in it), and now it
> works.
>
> There are two theories here in the office. One is
> that there is a compiler bug in flex so that bindings
> are not always properly recognized. That's the old
> pre-me theory.
>
> My theory is that there is no problem with flex, but
> that we are not properly initializing variables, and
> that certain changes get made during initialization
> "under the radar" of the binding mechanism.
>
> First, it is easy to mistakenly break binding:
>
> <MyFirstObject initialize="handleInit()" >
> <mx:Script>
> public var innerWidth: Number;
> public function handleInit() {
> innerWidth=myOtherObject.otherWidth;
> }
> </mx:Script>
>
> <mx:Image width="{innerWidth}" />
> </MyFirstObject>
>
> <MyOtherObject initialize="handleInit()" >
> <mx:Script>
> public var otherWidth: Number;
> public function handleInit() {
> otherWidth=55;
> }
> </mx:Script>
> </MyOtherObject>
>
> Width in the Image component is properly bound to
> innerWidth--any time innerWidth changes, so should
> width. The problem is, innerWidth only changes one
> time, in handleInit, when it is set, not bound,
> to MyOtherObject.otherWidth. If
> MyFirstObject.handleInit() is called before
> MyOtherObject.handleInit(), innerWidth will be
> undefined, and never changed again.
>
> The second issue, I believe, is that the bindings are
> only executed at a particular time during the
> initialization process. (Specifically, in
> constructObject2, after createChildren.) It is
> possible, as I said, to get that out of order so that
> the binding mechanism "fires" too soon, and not again.
>
> So anyway, those are the two competing theories around
> here: compiler bug, or subtleties in initialization
> order that we do not appreciate.
>
> Either way, I believe it is clear that binding is not
> as robust as we'd wish, during initialization. And at
> any rate, understanding better how something works is
> always a good thing!
>
> Greg
>
>
>
>
> --- JesterXL <[EMAIL PROTECTED]> wrote:
>
> > 2 things to do to ensure you're not nuts.
> >
> > 1. Add &recompile=true to the end of the URL string.
> > Slows compiling, but
> > it's worth the piece of mind.
> >
> > 2. Delete generated everytime you want to be sure
> > your changes are in fact
> > taking. Mine's here for Flex 1.5:
> >
>
C:\JRun4\servers\starExhibits\cfusion-ear\cfusion-war\WEB-INF\flex\generated
> >
> > LOL!!!! Royal... AWESOME. Whew, that made my
> > Thursday. Mmmm, tasty
> > burger!!!!
> >
> > First off, bindings are supposed to free you from
> > initialization worries.
> > Here's how it was in Flash:
> > - capture data in member var
> > - create asset
> > - wait a frame
> > - set data
> > - delete member var
> > - repeat process in convulted way
> >
> > In Flex? Bind value in View and it'll "work" when
> > she's created. Pimp!
> >
> > I'm sorry to hear it's not working that way for you.
> > Here's the rundown.
> >
> > - init
> > - createChildren
> > - initial drawing
> > * initialize is before everything is done drawing
> > - createChildren is the last event fired when
> > everyone and their mom is
> > ready
> >
> > There is a good rundown of this on Adobe's DevNet
> > site. If you want the
> > link, I can go find; it's a pretty good explanation.
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
