Sorry for the double post, but you have to know how you just saved my @$$!

I wrote my last comment only after reading your article. I applied into real time and ran my application for the first time just seconds ago. WOW!!!!

I think I will be spending the rest of the day rewriting about 2,000 lines of code.

Here was my mistake….
I was creating a public property that was bindable in my control. Binding it to my child controls in multiple places. I changed it to the process above and nearly fell off my chair. Not to mention it fixed a couple timing issues that I could not get rid of from my previous process. Ignorance is not always Bliss.

The kicker is that I was binding to bitmap classes that were being embedded. Who knows how many times the application reapplied the binding before finishing.

I hope you post the rest of the articles soon, so I can rewrite some more code.

You DA MAN!!!

Regards,
Tony

Thank you for helping me realize the errors of my noob ways!

Nice set of code and framework. I will be considering your components for my applications as they mature.

Thanks again,
Tony

Just started working on a custom and complex item renderer and I started to look back at these article for some guidance. One thing that I would like to hear you sound off on is some thoughts about the usage of the invalidateSomething methods.

They are all related to their respective calls as such:
invalidateProperties => commitProperties
invalidateDisplayList => updateDisplayList
invalidateSize => measure

I have seen similar approaches in the mx code base for using update flags for the display list. Can you talk a bit about that as well?

Thanks,
jwopitz

The benefit with using international standards when creating software is that you can blame to stupid design decisions on “an international team of brilliant computer scientists. That way, if someone tries to body-check you on the pathetic implementat…

I have been busy in the laboratory. Sometimes it seems like posting blog posts is harder than it actually is. If you have seen some of my components, you will understand my time is limited.

Not to mention I just finished up converting DocumentFX to apollo. That application has about 200 classes so it was a bit time consuming. I did manager to get it creating UML diagrams of class frameworks in the Flex UI. I still havn’t decided what I am going to do with it. Would be fun to release but, for now I am just using it for my own component development docs.

Ha, maybe there are others waiting to. I will see about getting some more up.

Peace, Mike

I know you are probably busy, but I thought I would let you know:

I AM EAGERLY AWAITING YOUR NEXT POST IN THIS SERIES!!!!

I haven’t been able to gather the time (nor willpower) to get back at component development or blogging.

Anywho…thanks for the great article.

jwopitz

Actually when I posted it in retrospect I thought of exactly what you are talking about. I need to find another word for ’state’. Something like ‘current property algorithm’.

I have a bunch of other things outlined that follow the same lines as these.

commitProperties() is a very powerful and underrated method in the template patter of the flex framework.

Adobe tends to actually code implementation into the commitProperties() methods. I don’t do that anymore because it tighlty couples the subclasses and you run into people complaining about private methods, properties and even plain ole rewritting the superclass method just to call something a little bit different.

Mike

I have noticed this approach used in some of the native Flex components but never really saw the value of the state change flags until reading this. Very insightful.

One recommendation I would make on this post and subsequent posts is to be very clear when using the word ’state’. In this case, you are using it as a synonym for var or property, which is fine for guys who have been doing this for some time. But some newcomers might get confused as the word state also relates with the UIComponent.currentState and mx:State objects.

Thanks for the great read.
jwopitz

Continue to unveil the rules of building solid custom Flex 2 components with a rest of the world and the rest of the world will greatly benefit.

We were luckily to read carefully Ely Greenfield’s preso at the beginning of 2007: http://www.flex.org/ACDS/BuildingAFlexComponent.pdf