>
I wonder if there is additional overhead associated with declaring untyped special
type variables (*) compared to typed variables? Yes, I believe there is; if the compiler
doesn't know anything about the type it can't optimize the generated code as
well. But there is no reason to use * here; you could declare var itm:Object
instead. The only reason to use * is when you need to store 'undefined' in
addition to 'null'. However, there is definitely an overhead
associated with using dynamic classes like Ojbect. If you want the best performance,
don't use dtynamic Objects like { label: xxx, color: yyy }; instead declare a nondynamic
ColorPickerDataProviderItem class with 'label' and 'color' properties. However, in this case I doubt you'll
actually be able to see any better performance because these objects don't get
accessed a huge number of times. - Gordon From: Thanks
for the great tips. The changes worked great. I wonder if there is
additional overhead associated with declaring untyped special type variables
(*) compared to typed variables? I
couldn't get the color picker focus border to dissapear completely.
Nothing that I tried with the FocusManager worked. I'm probably just
doing it wrong. But, for now the sample is good enough to demonstrate the
ComboBox ItemRenderer concepts. Thanks
again, -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
- RE: [flexcoders] Re: F2B3: Possible bugs with ComboBox ItemRe... Gordon Smith