Couple of things - it appears that in your test case, the textDisplay is of
0 width and height. If you debug through, you will notice that it does not
actually capture the screen shot. Second, this wont work on the emulator,
since it depends on SoftKeyboardEvent.SOFT_KEYBOARD_ACTIVATE and
SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE events.
but try the below. it should atleast capture the screenshot.
override protected function createChildren():void
{
super.createChildren();
this.textDisplay.addEventListener(ResizeEvent.RESIZE, invalidateScreenshot);
this.textDisplay.addEventListener(TextOperationEvent.CHANGE,
invalidateScreenshot);
}
The one thing is that the screenshot is not capturing the text in your test
case. Not sure why. Maybe the experts on here could help shed some light.
It might be that we simply need to wait a little more before capturing the
screenshot. It is odd that this works perfectly on our client application
but not in a simple test case like this. For our scenario, we have a fairly
large Flex 3 based application with tons of forms that we converted to Flex
4.10/11. It is working for us.
On Sun, Nov 17, 2013 at 1:31 PM, Maurice Amsellem <
maurice.amsel...@systar.com> wrote:
> @Flexicious,
>
> FYI, I have tried the ExtendedStageTextInputSkin and it does not solve at
> all the scrolling problem:
>
> - Simple code to show the issue below:
> - Run the app even in the ADL, and scroll the Form: the TextInput stays
> in place.
>
> Can you confirm the behavior on your side ?
>
> <s:Scroller height="100%" width="100%" horizontalScrollPolicy="off">
> <s:Group>
> <s:Form height="100%">
> <s:FormItem label="Label">
> <s:Label height="300" text="BEFORE"/>
> </s:FormItem>
> <s:FormItem label="TextInput with default Skin and
> softkeyboard=number">
> <s:TextInput id="ti1" width="100%" text="TEXT1"
> skinClass="skins.ExtendedStageTextInputSkin"/>
> </s:FormItem>
> <s:FormItem label="Label">
> <s:Label height="800" text="AFTER"/>
> </s:FormItem>
> </s:Form>
> </s:Group>
> </s:Scroller>
>
> -----Message d'origine-----
> De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
> Envoyé : dimanche 17 novembre 2013 18:34
> À : dev@flex.apache.org
> Objet : RE: Air Stage Text Issue
>
> Ok, thanks.
> I am too advanced now in my implementation to drop everything and use your
> code instead, but I will keep it in case I get into a deadlock.
> And of course, I will use it as a reference implementation.
>
> >It is not a perfect solution, but for the subset of scenarios that this
> current client cared about, it seems to work.
> Can you please detail some use cases where it does not work (apart from
> the occluding stuff). That could also help me since I am taking almost the
> same approach.
>
> Maurice
>
> -----Message d'origine-----
> De : Flexicious.com [mailto:flexici...@gmail.com] Envoyé : dimanche 17
> novembre 2013 18:28 À : dev@flex.apache.org Objet : Re: Air Stage Text
> Issue
>
> Yes, it seems to work on iPad 2/3/4 as well as Samsung Galaxy Tab 2 . Have
> not tested on phones, but doubt it should be different. It is not a perfect
> solution, but for the subset of scenarios that this current client cared
> about, it seems to work.
>
>
>
>
> On Sun, Nov 17, 2013 at 12:08 PM, Maurice Amsellem <
> maurice.amsel...@systar.com> wrote:
>
> > Thank you Mr. Flexicious for the code :-)
> >
> > I am taking pretty much the same approach, expect that I have
> > encapsulated StageText and ImageProxy in its own class, like in
> StyleableStageText.
> > That way, it can be reused in TextAreaStageSkin as well.
> >
> > There is something I don't understand in your implementation:
> > StyleableStageText implementation is very complex, because the
> > StageText which is always displayed, does not belong to the DL, while
> > the proxyImage is displayed only in some situations (throw effect
> > after scroll and nested popups).
> >
> > I tried to tweak it like you did, and abandoned, because the approach
> > we are taking ( proxyimage displayed by default, and stage text when
> > editing) is antagonist to the one implemented in SST, and the tweaking
> > code was actually more complex that rewriting everything from scratch.
> >
> > So I am rather surprized that you managed to conciliate both and that
> > the resulting code is so simple.
> > Don't you have some side effects ? does it work on Android as well?
> >
> > Maurice
> >
> > -----Message d'origine-----
> > De : Flexicious.com [mailto:flexici...@gmail.com] Envoyé : dimanche 17
> > novembre 2013 17:31 À : dev@flex.apache.org Objet : Re: Air Stage Text
> > Issue
> >
> > For what its worth, we have a skin that solves the issue atleast for
> > our scenarios.
> >
> > http://blog.flexicious.com/post/Scrolling-Issues-With-TextInput-for-Fl
> > ex-Air-Mobile-Native-StageText.aspx
> > .
> > It may not be the best workaround, but its better than what we had.
> > For us, it was not only scrolling, but things like dropdowns and date
> > pickers (which we also skinned for mobile) appeared underneath the stage
> text.
> >
> >
> >
> > On Sun, Nov 17, 2013 at 10:29 AM, Alex Harui <aha...@adobe.com> wrote:
> >
> > >
> > >
> > > On 11/17/13 2:59 AM, "Maurice Amsellem"
> > > <maurice.amsel...@systar.com>
> > > wrote:
> > >
> > > >>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.
> > > And note that, in most cases, the next best solution is to modify
> > > the application code so that scrolling is not needed. Just have
> > > more screens that you can swipe between. That kind of modification
> > > might be better than trying to implement code that makes sure text
> > > inputs don't get partially clipped.
> > > >
> > > >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
> > > >:-(
> > > Well, they are already complaining, so I doubt things will get worse.
> > >
> > > -Alex
> > >
> > >
> >
>
