] On
Behalf Of Alex Harui
Sent: Wednesday, August 06, 2008 7:35 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Must call super.commitProperties at END of
overrided commitProperties when extending TitleWindow?
Well, I said you were strict and not wrong. I've heard others say
I don't think I've seen anything like this before and maybe I'm just going
crazy.
I've got a class that extends TitleWindow, it has a few setters and some of
these can affect what the displayed title should be. These all use
invalidation flags and don't get fully committed until commitProperties.
The title property is simply a property that gets passed to the title
UIComponent in commitproperties. Timeline:
1. You call super.commitProperties()
2. super.commitProperties() sees that this._title hasn't changed since the
last commitProperties(). so doesn't set _myTitleComponent.title (or
it should have still updated on the next invalidation pass because in
Panel.as my call to set title sets _titleChanged = true, which should cause
that logic block to execute in the next commitProperties. Maybe I was off in
debugging and never hit another invalidation pass.
This does bring up a
After a quick poke around in Panel.as, it seems that what I described isn't
*exactly* what's going on, you might want to do some single-stepping to see
where it's going wrong. But the root probelm is the same, and the solution
isn't to put super.commitProperties() at the end of your method. You
@yahoogroups.com
Subject: Re: [flexcoders] Must call super.commitProperties at END of
overrided commitProperties when extending TitleWindow?
After a quick poke around in Panel.as, it seems that what I described
isn't *exactly* what's going on, you might want to do some
single-stepping to see where it's going
super.commitProperties at END of
overrided commitProperties when extending TitleWindow?
it should have still updated on the next invalidation pass because in
Panel.as my call to set title sets _titleChanged = true, which should
cause that logic block to execute in the next commitProperties. Maybe
I guess :)
I just *really* don't like a situation where the position of
super.whatever() affects whether or not it works. Frankly If I were
designing a language super.foo() would be the default, and there'd be a
keyword to block it.
If super.commitProperties() can be expected to be anywhere
] On
Behalf Of Josh McDonald
Sent: Wednesday, August 06, 2008 6:31 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Must call super.commitProperties at END of
overrided commitProperties when extending TitleWindow?
I guess :)
I just *really* don't like a situation where the position
*To:* flexcoders@yahoogroups.com
*Subject:* Re: [flexcoders] Must call super.commitProperties at END of
overrided commitProperties when extending TitleWindow?
I guess :)
I just *really* don't like a situation where the position of
super.whatever() affects whether or not it works. Frankly
in.
--
*From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
Behalf Of *Josh McDonald
*Sent:* Wednesday, August 06, 2008 6:31 PM
*To:* flexcoders@yahoogroups.com
*Subject:* Re: [flexcoders] Must call super.commitProperties at END of
overrided commitProperties when
11 matches
Mail list logo
