>For point #1 (TI scrolled to top): >- One possibility would be to prevent editing when text in partially >obscured. >- Another would be to scroll it back to view, so that it's not obscured >anymore.
>Neither of these proposed solutions are 'perfect'. They will cause some >grumbling from users, questions on the forums, etc. >At Adobe, that would often cause us to pull the plug on >doing something. >That doesn't have to be true at Apache Flex. >Especially if you can encapsulate your proposed solutions in a skin class, >folks can try it, and choose something else if they >don't like it. I understand what you mean. The "perfect" solution, would be to have a "StageMask" or something that would be displayed in front of the edited StageText to reproduced the partial occluding. It could be simulated by a StageWebView containing the TI and a bitmap with alpha mask that reproduces the masking area, but that's too much work for me. In the meantime, I have to choose something simple, because I only have a limited time to dedicate to this. The approach I am taking now ( using proxy always and StageText when editing) is ALREADY a full rewriting of the TI Skin... What I am saying to myself to get some motivation to go ahead, is that the "partial occluding" issue could be solved by modifying the application code, so that nothing comes in the way Of the edited text. But I know that it won't prevent people from coming to this forum (because the other Flex fora are not active) and calling us names :-( At least, I will try to... Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : dimanche 17 novembre 2013 06:12 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue On 11/16/13 4:52 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >>Suppose you have a TextInput that scrolls so all but the top 10 pixels >>are visible. Are you going to show the bitmap or the StageText when >>they give it focus? I think you have to show the >StageText in which >>case it will float over the top and look bad. Same if there is a >>floating dialog or icon that partially obscures the TextInput when it >>has focus. > >Got it, thanks for the explanations. > >For point #1 (TI scrolled to top): >- One possibility would be to prevent editing when text in partially >obscured. >- Another would be to scroll it back to view, so that it's not obscured >anymore. Neither of these proposed solutions are 'perfect'. They will cause some grumbling from users, questions on the forums, etc. At Adobe, that would often cause us to pull the plug on doing something. That doesn't have to be true at Apache Flex. Especially if you can encapsulate your proposed solutions in a skin class, folks can try it, and choose something else if they don't like it. That's why FlexJS is trying to plug-ins throughout the framework: you can swap out things you don't like for things that might better meet your needs. > >For point #2 ( TI partially obscured by floating component): >- I think it should be possible to detect that the text is occluded, >and prevent editing in this case. Again, not a 'perfect' solution. It could be the last pixel of a dropshadow of a floating spell-check dialog that then blocks editing. Or some fuzz on the focus ring itself. IMO, if you want to code up some attempts for folks to try, by all means do so. BTW, you didn't ask about the text selection, but that is also a concern. Let's say you scroll and the top-most row of pixels of a TextInput is now clipped. How do you let someone touch and drag to select some text? Anyway, good luck and have fun if that's what you want to pursue. I'm hoping that FlexJS output through Cordova will turn out to be viable and skip around these sorts of fidelity issues. -Alex
