The emulations often started from the actual Flex component. The code in a method/getter/setter was often commented out to get things to compile.
Getting things to run is DAYG (do as you go). When it is time to actually get some method/getter/setter to work again, some of the things to consider are: -Are there beads and utility classes that can be leveraged to get it to work? The emulation of UIComponent is a subclass of Basic components, so in many cases the right bead needs to be used or subclassed and modified a bit. However, Spark TextInput is pretty unique because it and Spark TextArea were configured to use TLF/FTE so there may not be beads you can leverage. - Is the commented out code useful? It was in Charts and other places because once enough stuff in UIComponent and elsewhere started to work it was possible to reuse a lot of the Flex code that didn't have Flash dependencies. - How much time will it take to "do the right thing"? So the first question is: what is working today? Do the Spark RichEditableText, TextInput and TextArea examples in tourdeflexmodules work? If so, do they do leverage the TLF code or how do they display text? While your changes probably work, the "right thing" would be to emulate IEditableText, uncomment the "textDisplay" in SkinnableTextBase and get most of that commented out code to work by calling the RichEditableText as the default textDisplay or however the working examples display their text. That way the changes you make would work for Spark TextArea as well. But if you only have so much time, then something is better than nothing. HTH, -Alex On 8/1/19, 9:10 AM, "Yishay Weiss" <[email protected]> wrote: >Do I understand correctly that the commented code which I removed was never meant to be fully >implemented and we can add functionality as we go? I meant the code in SkinnableTextBase.text I didn’t remove it, just not relying on it.
