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 point about the invalidation mechanism however. Because I really shouldn't know which properties are handled with invalidation flags in a class I'm extending, I should always put the call to super.commitProperties at the end of my commitProperties functions just in case something in that function changes a property that calls invalidateProperties. I definitely don't want to rely on another frame calling invalidateProperties as it may never happen and I can't control when it happens. What if a function call in commitProperties ends up dispatching an event and some handler code executes that modifes title or some other code handled by an invalidation flag. Only way to guarantee all those changes are picked up is to call super after my code executes, which still looks bizarre to me. On Wed, Aug 6, 2008 at 6:44 PM, Josh McDonald <[EMAIL PROTECTED]> wrote: > 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 > _titleLabel.text, whatever, but you get the idea) > > 3. You change this.title to "Boo!" > > 4. super.set title() sets this._title = "Boo!" > > 5. super.set title() calls invalidateProperties() > > 6. Flex realises you're already inside this.commitProperties for the > instance in question, and ignores the invalidateProperties(). - If it > didn't, you'd get an endless loop. > > Result: The title on screen doesn't get updated in this "validate > properties" phase. > > Next time your commitProperties gets run, when you call this.title = "Boo!" > it checks, realises that this._title *already* equals "Boo!", so it never > marks the _title property as changed, so super.commitProperties() never > bothers to update _myTitleComponent.title > > Result: It *never* makes it to the screen. > > -Josh > > > On Thu, Aug 7, 2008 at 9:25 AM, Daniel Gold <[EMAIL PROTECTED]> wrote: > >> 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. If >> I call super.commitProperties() at the beginning of my commitProperties >> function, and then change the title somewhere else in that function, the >> title NEVER gets commited. I've stepped through the code and I really can't >> see why. There are only two places in Panel.as that modify _titleChanged. I >> see it getting flipped to true in the setter, then when commitProperties >> gets around to executing, the flag is magically false? >> >> Anyways, if I call super.commitProperties after I do all my work and >> possibly modify the title, everything is fine, except it looks really whacky >> because I've had it ingrained for years that you always call super class >> functions at the beginning... >> >> A subclass of TitleWindow as simple as this exhibits the behavior: >> >> <?xml version="1.0" encoding="utf-8"?> >> <mx:TitleWindow xmlns:mx="http://www.adobe.com/2006/mxml"; >> layout="absolute" width="400" height="300"> >> >> <mx:Script> >> <![CDATA[ >> >> override protected function commitProperties():void >> { >> super.commitProperties(); >> title = "ljsdflksjdflkj"; >> } >> >> ]]> >> </mx:Script> >> </mx:TitleWindow> >> > > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > >
