Doug, certainly I welcome you to join in the
conversation. The more heads and opinions the better.
But I'm afraid you didn't read my post carefully
enough--my entire point was that I believe our
problems are programmer error rather than a compiler
bug. That was the central question of my email, and
the code I included was to illustrate how easy it is
to make such errors!
The purpose of this thread is to try to gain a better
understanding of the order of initialization in
Flex--the interactions between constructObject2, init,
createChildren, and how those interact with bindings.
Greg
--- Doug Lowder <[EMAIL PROTECTED]> wrote:
> 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
> >
>
>
>
>
>
__________________________________________________
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/
