On 8/17/14 4:04 PM, "jude" wrote:
>Thanks for the clarification. I forgot about backward compatibility. As
>for
>code complete, in the Design Extensions Readme Kit.txt I found this
>reference:
>
>PicnicExtensions
This part is specific to design extensions. If a TextInput is proxied by
a Design
Thanks for the clarification. I forgot about backward compatibility. As for
code complete, in the Design Extensions Readme Kit.txt I found this
reference:
PicnicExtensions
This is a Flex Library project that defines the design view extension
classes
for the picnic components. Note that th
Interesting. I'd never heard of auto-complete as a reason to use
ExcludeClass. Size of documentation is a concern, but the main issue,
IMO, regarding private, @private, mx_internal and/or ExcludeClass is about
backward-compatibility. Once you document it, you can't go changing it
without fear of
For discussion, I think we should remove the [ExcludeClass] from all the
classes in the SDK. The reasons are mainly that I've found really useful
classes usually after the fact that were excluded from auto complete and
documentation. The reasons for ExcludeClass seem to be to make auto
complete fas
