I don't understand that use case. In the suggested scenario, you have a bitmap all the time except if the TextInput has focus. Once it has focus you would show the StageText. This is the same time that the virtual keyboard pops up. I don't think there's any other way except the it behaves now. I don't think it will look bad because the StageText also is clipped itself. As soon as the TextInput loses focus you show the bitmap again.
There is code in Flex (or AIR?) that is clipping the StageText successfully but I think the problem is that when you scroll it's not always validated. For example, if you scroll or throw a view that has a text input / text area in it the text area is not clipped. Then it overlaps. If you invalidate the TextInput style (call styleChange) then something happens and it's correctly clipped. I spent a few days trying to figure out a cheaper way to fix it but all I could come up with is calling styleChanged on animation end. I think this is what we're talking about? On Sat, Nov 16, 2013 at 6:07 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/16/13 12:19 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> > wrote: > >>3) I'm not sure proxying would handle partially occluded text inputs. > >What do you mean, by partially occluded text input ? > >Is it that the TextInput is clipped or that there is something in front ? > Either. > > > >I don't understand why this would be an issue with bitmap proxying. Can > >you please elaborate. > 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. > > -Alex > >
