You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Maurice Amsellem <ma...@systar.com> on 2013/11/16 14:17:35 UTC
Air Stage Text Issue
Hi,
I am currently working on the issue about StageTextInput not scrolling on mobile:
https://issues.apache.org/jira/browse/FLEX-33166
Debugging the SDK source code, it appears that "proxying" the StageTextInput with a bitmap is already in place (see class StyleableStageText).
However, the proxy bitmap is shown in only very specific situations:
- a stage animation that contains the stage text is playing (example: Touch "throw" animation, that happens when you *release* your finger after swiping )
- popup is opened , in which case all text input below in the z-order are proxied to bitmaps
Another rather "radical" approach, which has been suggested by some ( DarkStone, Flexicious), would be to always display a StageText as a proxy bitmap when it's visible,
and to show the StageText only when typing text via the soft keyboard.
It's hard for me to believe that the Adobe SDK team went into all the pain of implementing the bitmap proxying, and the complex popup depth calculations (cf. StyleableStageText 3000+ lines of code) and didn't think about such a simple approach.
So there must be something else!
Some ideas come to mind:
- memory concerns: maintaining bitmap proxies for all visible text inputs (and text areas), especially on high resolution displays, can be very costly.
- time: maybe Flex was stopped at Adobe before this approach could be implemented, and TI was left in an intermediate state...
Or maybe, they didn't see the scrolling issue... nobody is perfect.
Does someone know ?
Maurice
-----Message d'origine-----
De : DarkStone [mailto:darkstone@163.com]
Envoyé : mercredi 30 octobre 2013 08:26
À : dev@flex.apache.org
Objet : Re:Re: Re:Air Stage Text Issue
Hi Naveen,
I haven't got time to implement it yet.
But I figure it out a better solution:
1. Create a class named "VisualStageText" which extends SpriteVisualElement class and implements IEditableText interface.
2. In the VisualStageText class implementation, define a private variable stageText:StageText, use it to implement IEditableText yourself, and also define a private variable snapshot:Bitmap.
3. Listen for VisualStageText instance's Event.ACTIVATE, Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other interaction relative events to detect user interactions.
4. When the user is currently interacting with VisualStageText, you need to hide the snapshot and show the stageText:
snapshot.parent ? removeChild(snapshot) : null; snapshot.bitmapData.dispose(); snapshot.bitmapData = null; stageText.stage = stage; stageText.viewPort = new Rectangle(...);
5. When the user is not interacting with VisualStageText, you need to take a snapshot of the stageText, then hide the stageText and display the snapshot:
var bd:BitmapData = new BitmapData(stageText.viewPort.width, stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
snapshot.bitmapData = bd;
stageText.stage = null;
addChild(snapshot);
Well this is it, this is the core concept of how to do a Flex version StageText, you can use the VisualStageText as a MXML tag, and bind it to the skinpart of the spark TextInput (or TextArea)'s textDisplay:IEditableText.
I plan to implement my VisualStageText at the end of this year, but if you can't wait you can do it by yourself, good luck : )
DarkStone
2013-10-30
At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>Hi DarkStone,
>
>Thank you for your post.
>
>Can you please share the code for the same as I am little confused on
>how to achieve this.
>
>Thanks is Advance
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Iss
>ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>list archive at Nabble.com.
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
Thank you for the information
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : lundi 18 novembre 2013 18:58
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
I asked him today. He pretty much confirmed what I said. The AIR team was in the process of trying to provide the solution, so we didn't invest time on it.
-Alex
On 11/18/13 7:41 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I can try to ask the engineer who worked on it to see if he remembers
>
>Hi Alex,
>
>Do you think you will be able to reach the above mentioned engineer in
>the coming days, to know why StyleableStageText was implemented that way ?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : samedi 16 novembre
>2013 19:32 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue
>
>I can try to ask the engineer who worked on it to see if he remembers,
>but I would guess the following:
>
>1) There was hope that AIR would provide a solution
>2) I'm not sure proxying would handle text selection.
>3) I'm not sure proxying would handle partially occluded text inputs.
>
>You're welcome to take a shot at it. Adobe generally didn't like
>half-baked solutions so if it there was no solution for
>partially-occluded text inputs it wouldn't provide a solution at all,
>but maybe it is worth offering a solution for folks who won't ever
>partially occlude their text inputs (which is probably a lot of folks).
>
>But before you go work on that, can you look at the most recent
>mustella failures? I think there is a new DataGrid failure.
>
>-Alex
>
>On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi,
>>
>>I am currently working on the issue about StageTextInput not scrolling
>>on
>>mobile:
>>https://issues.apache.org/jira/browse/FLEX-33166
>>
>>
>>Debugging the SDK source code, it appears that "proxying" the
>>StageTextInput with a bitmap is already in place (see class
>>StyleableStageText).
>>
>>However, the proxy bitmap is shown in only very specific situations:
>>- a stage animation that contains the stage text is playing (example:
>>Touch "throw" animation, that happens when you *release* your finger
>>after swiping )
>>- popup is opened , in which case all text input below in the z-order
>>are proxied to bitmaps
>>
>>Another rather "radical" approach, which has been suggested by some (
>>DarkStone, Flexicious), would be to always display a StageText as a
>>proxy bitmap when it's visible, and to show the StageText only when
>>typing text via the soft keyboard.
>>
>>It's hard for me to believe that the Adobe SDK team went into all the
>>pain of implementing the bitmap proxying, and the complex popup depth
>>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>>think about such a simple approach.
>>So there must be something else!
>>
>>Some ideas come to mind:
>>- memory concerns: maintaining bitmap proxies for all visible text
>>inputs (and text areas), especially on high resolution displays, can
>>be very costly.
>>- time: maybe Flex was stopped at Adobe before this approach could be
>>implemented, and TI was left in an intermediate state...
>>
>>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>>
>>Does someone know ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : DarkStone [mailto:darkstone@163.com] Envoyé : mercredi 30 octobre
>>2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text
>>Issue
>>
>>Hi Naveen,
>>
>>I haven't got time to implement it yet.
>>
>>But I figure it out a better solution:
>>
>>1. Create a class named "VisualStageText" which extends
>>SpriteVisualElement class and implements IEditableText interface.
>>
>>2. In the VisualStageText class implementation, define a private
>>variable stageText:StageText, use it to implement IEditableText
>>yourself, and also define a private variable snapshot:Bitmap.
>>
>>3. Listen for VisualStageText instance's Event.ACTIVATE,
>>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>>interaction relative events to detect user interactions.
>>
>>4. When the user is currently interacting with VisualStageText, you
>>need to hide the snapshot and show the stageText:
>>snapshot.parent ? removeChild(snapshot) : null;
>>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>>
>>5. When the user is not interacting with VisualStageText, you need to
>>take a snapshot of the stageText, then hide the stageText and display
>>the
>>snapshot:
>>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>>snapshot.bitmapData = bd;
>>stageText.stage = null;
>>addChild(snapshot);
>>
>>Well this is it, this is the core concept of how to do a Flex version
>>StageText, you can use the VisualStageText as a MXML tag, and bind it
>>to the skinpart of the spark TextInput (or TextArea)'s
>>textDisplay:IEditableText.
>>
>>I plan to implement my VisualStageText at the end of this year, but if
>>you can't wait you can do it by yourself, good luck : )
>>
>>
>>DarkStone
>>2013-10-30
>>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>>Hi DarkStone,
>>>
>>>Thank you for your post.
>>>
>>>Can you please share the code for the same as I am little confused on
>>>how to achieve this.
>>>
>>>Thanks is Advance
>>>
>>>
>>>
>>>--
>>>View this message in context:
>>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-I
>>>s s ue-tp30223p31670.html Sent from the Apache Flex Development
>>>mailing list archive at Nabble.com.
>>
>
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
I asked him today. He pretty much confirmed what I said. The AIR team
was in the process of trying to provide the solution, so we didn't invest
time on it.
-Alex
On 11/18/13 7:41 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I can try to ask the engineer who worked on it to see if he remembers
>
>Hi Alex,
>
>Do you think you will be able to reach the above mentioned engineer in
>the coming days, to know why StyleableStageText was implemented that way ?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : samedi 16 novembre 2013 19:32
>À : dev@flex.apache.org
>Objet : Re: Air Stage Text Issue
>
>I can try to ask the engineer who worked on it to see if he remembers,
>but I would guess the following:
>
>1) There was hope that AIR would provide a solution
>2) I'm not sure proxying would handle text selection.
>3) I'm not sure proxying would handle partially occluded text inputs.
>
>You're welcome to take a shot at it. Adobe generally didn't like
>half-baked solutions so if it there was no solution for
>partially-occluded text inputs it wouldn't provide a solution at all, but
>maybe it is worth offering a solution for folks who won't ever partially
>occlude their text inputs (which is probably a lot of folks).
>
>But before you go work on that, can you look at the most recent mustella
>failures? I think there is a new DataGrid failure.
>
>-Alex
>
>On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi,
>>
>>I am currently working on the issue about StageTextInput not scrolling
>>on
>>mobile:
>>https://issues.apache.org/jira/browse/FLEX-33166
>>
>>
>>Debugging the SDK source code, it appears that "proxying" the
>>StageTextInput with a bitmap is already in place (see class
>>StyleableStageText).
>>
>>However, the proxy bitmap is shown in only very specific situations:
>>- a stage animation that contains the stage text is playing (example:
>>Touch "throw" animation, that happens when you *release* your finger
>>after swiping )
>>- popup is opened , in which case all text input below in the z-order
>>are proxied to bitmaps
>>
>>Another rather "radical" approach, which has been suggested by some (
>>DarkStone, Flexicious), would be to always display a StageText as a
>>proxy bitmap when it's visible, and to show the StageText only when
>>typing text via the soft keyboard.
>>
>>It's hard for me to believe that the Adobe SDK team went into all the
>>pain of implementing the bitmap proxying, and the complex popup depth
>>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>>think about such a simple approach.
>>So there must be something else!
>>
>>Some ideas come to mind:
>>- memory concerns: maintaining bitmap proxies for all visible text
>>inputs (and text areas), especially on high resolution displays, can be
>>very costly.
>>- time: maybe Flex was stopped at Adobe before this approach could be
>>implemented, and TI was left in an intermediate state...
>>
>>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>>
>>Does someone know ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : DarkStone [mailto:darkstone@163.com] Envoyé : mercredi 30 octobre
>>2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text
>>Issue
>>
>>Hi Naveen,
>>
>>I haven't got time to implement it yet.
>>
>>But I figure it out a better solution:
>>
>>1. Create a class named "VisualStageText" which extends
>>SpriteVisualElement class and implements IEditableText interface.
>>
>>2. In the VisualStageText class implementation, define a private
>>variable stageText:StageText, use it to implement IEditableText
>>yourself, and also define a private variable snapshot:Bitmap.
>>
>>3. Listen for VisualStageText instance's Event.ACTIVATE,
>>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>>interaction relative events to detect user interactions.
>>
>>4. When the user is currently interacting with VisualStageText, you
>>need to hide the snapshot and show the stageText:
>>snapshot.parent ? removeChild(snapshot) : null;
>>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>>
>>5. When the user is not interacting with VisualStageText, you need to
>>take a snapshot of the stageText, then hide the stageText and display
>>the
>>snapshot:
>>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>>snapshot.bitmapData = bd;
>>stageText.stage = null;
>>addChild(snapshot);
>>
>>Well this is it, this is the core concept of how to do a Flex version
>>StageText, you can use the VisualStageText as a MXML tag, and bind it
>>to the skinpart of the spark TextInput (or TextArea)'s
>>textDisplay:IEditableText.
>>
>>I plan to implement my VisualStageText at the end of this year, but if
>>you can't wait you can do it by yourself, good luck : )
>>
>>
>>DarkStone
>>2013-10-30
>>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>>Hi DarkStone,
>>>
>>>Thank you for your post.
>>>
>>>Can you please share the code for the same as I am little confused on
>>>how to achieve this.
>>>
>>>Thanks is Advance
>>>
>>>
>>>
>>>--
>>>View this message in context:
>>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Is
>>>s ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>>>list archive at Nabble.com.
>>
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>I can try to ask the engineer who worked on it to see if he remembers
Hi Alex,
Do you think you will be able to reach the above mentioned engineer in the coming days, to know why StyleableStageText was implemented that way ?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : samedi 16 novembre 2013 19:32
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
I can try to ask the engineer who worked on it to see if he remembers, but I would guess the following:
1) There was hope that AIR would provide a solution
2) I'm not sure proxying would handle text selection.
3) I'm not sure proxying would handle partially occluded text inputs.
You're welcome to take a shot at it. Adobe generally didn't like half-baked solutions so if it there was no solution for partially-occluded text inputs it wouldn't provide a solution at all, but maybe it is worth offering a solution for folks who won't ever partially occlude their text inputs (which is probably a lot of folks).
But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure.
-Alex
On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi,
>
>I am currently working on the issue about StageTextInput not scrolling
>on
>mobile:
>https://issues.apache.org/jira/browse/FLEX-33166
>
>
>Debugging the SDK source code, it appears that "proxying" the
>StageTextInput with a bitmap is already in place (see class
>StyleableStageText).
>
>However, the proxy bitmap is shown in only very specific situations:
>- a stage animation that contains the stage text is playing (example:
>Touch "throw" animation, that happens when you *release* your finger
>after swiping )
>- popup is opened , in which case all text input below in the z-order
>are proxied to bitmaps
>
>Another rather "radical" approach, which has been suggested by some (
>DarkStone, Flexicious), would be to always display a StageText as a
>proxy bitmap when it's visible, and to show the StageText only when
>typing text via the soft keyboard.
>
>It's hard for me to believe that the Adobe SDK team went into all the
>pain of implementing the bitmap proxying, and the complex popup depth
>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>think about such a simple approach.
>So there must be something else!
>
>Some ideas come to mind:
>- memory concerns: maintaining bitmap proxies for all visible text
>inputs (and text areas), especially on high resolution displays, can be
>very costly.
>- time: maybe Flex was stopped at Adobe before this approach could be
>implemented, and TI was left in an intermediate state...
>
>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>
>Does someone know ?
>
>Maurice
>
>-----Message d'origine-----
>De : DarkStone [mailto:darkstone@163.com] Envoyé : mercredi 30 octobre
>2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text
>Issue
>
>Hi Naveen,
>
>I haven't got time to implement it yet.
>
>But I figure it out a better solution:
>
>1. Create a class named "VisualStageText" which extends
>SpriteVisualElement class and implements IEditableText interface.
>
>2. In the VisualStageText class implementation, define a private
>variable stageText:StageText, use it to implement IEditableText
>yourself, and also define a private variable snapshot:Bitmap.
>
>3. Listen for VisualStageText instance's Event.ACTIVATE,
>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>interaction relative events to detect user interactions.
>
>4. When the user is currently interacting with VisualStageText, you
>need to hide the snapshot and show the stageText:
>snapshot.parent ? removeChild(snapshot) : null;
>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>
>5. When the user is not interacting with VisualStageText, you need to
>take a snapshot of the stageText, then hide the stageText and display
>the
>snapshot:
>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>snapshot.bitmapData = bd;
>stageText.stage = null;
>addChild(snapshot);
>
>Well this is it, this is the core concept of how to do a Flex version
>StageText, you can use the VisualStageText as a MXML tag, and bind it
>to the skinpart of the spark TextInput (or TextArea)'s
>textDisplay:IEditableText.
>
>I plan to implement my VisualStageText at the end of this year, but if
>you can't wait you can do it by yourself, good luck : )
>
>
>DarkStone
>2013-10-30
>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>Hi DarkStone,
>>
>>Thank you for your post.
>>
>>Can you please share the code for the same as I am little confused on
>>how to achieve this.
>>
>>Thanks is Advance
>>
>>
>>
>>--
>>View this message in context:
>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Is
>>s ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>>list archive at Nabble.com.
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>There is code in Flex (or AIR?) that is clipping the StageText successfully
Not it does not, even if you set a viewport that is smaller that the StageText, it will be displayed in its entirety, expected if clipped by the screen device, which is not what we are talking about (see Alex comment).
>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?
It's not the StageText that is displayed when you "throw", but the proxyImage. That's why it's clipped and scrolled correctly.
However, during the scrolling (finger not released), It's the StageText, and it's does not even scroll with the rest(let alone clipping).
That's the main issue.
Maurice
-----Message d'origine-----
De : jude [mailto:flexcapacitor@gmail.com]
Envoyé : dimanche 17 novembre 2013 04:44
À : dev
Objet : Re: Air Stage Text Issue
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?
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
On 11/16/13 7:44 PM, "flexcapacitor@gmail.com" <fl...@gmail.com>
wrote:
>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.
I think you are thinking of TextInputs clipped by screen boundaries, but
what about a TextInput clipped by the title bar of a Panel? When given
focus, I think the StageText will obscure part of the titlebar and look
bad. I think that's why we wanted AIR to fix it.
>
>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?
I don't honestly know. I haven't worked with StageText myself. I guess
we'll find out as Maurice and others attempt solutions.
-Alex
Re: Air Stage Text Issue
Posted by jude <fl...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 11/16/13 12:19 PM, "Maurice Amsellem" <ma...@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
>
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>this wont work on the emulator, since it depends on SoftKeyboardEvent.SOFT_KEYBOARD_ACTIVATE and SoftKeyboardEvent.SOFT_KEYBOARD_DEACTIVATE events.
It doesn't work on the iPad either: scroll up and dow several times and you will notice the TI sometimes shows and sometimes does not show while you scroll.
>but try the below. it should atleast capture the screenshot.
Sorry, I will not have time to test fixes on your patch. I hope you understand.
Anyway, the new implementation is almost complete.
So maybe if you could test it on your scenarios, on different devices, that would help us a lot.
Thnaks
Maurice
-----Message d'origine-----
De : Flexicious.com [mailto:flexicious@gmail.com]
Envoyé : dimanche 17 novembre 2013 19:59
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
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.amsellem@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.amsellem@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:flexicious@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.amsellem@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:flexicious@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 <ah...@adobe.com> wrote:
> >
> > >
> > >
> > > On 11/17/13 2:59 AM, "Maurice Amsellem"
> > > <ma...@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
> > >
> > >
> >
>
Re: Air Stage Text Issue
Posted by "Flexicious.com" <fl...@gmail.com>.
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.amsellem@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.amsellem@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:flexicious@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.amsellem@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:flexicious@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 <ah...@adobe.com> wrote:
> >
> > >
> > >
> > > On 11/17/13 2:59 AM, "Maurice Amsellem"
> > > <ma...@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
> > >
> > >
> >
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
@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.amsellem@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:flexicious@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.amsellem@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:flexicious@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 <ah...@adobe.com> wrote:
>
> >
> >
> > On 11/17/13 2:59 AM, "Maurice Amsellem"
> > <ma...@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
> >
> >
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
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:flexicious@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.amsellem@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:flexicious@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 <ah...@adobe.com> wrote:
>
> >
> >
> > On 11/17/13 2:59 AM, "Maurice Amsellem"
> > <ma...@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
> >
> >
>
Re: Air Stage Text Issue
Posted by "Flexicious.com" <fl...@gmail.com>.
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.amsellem@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:flexicious@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-Flex-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 <ah...@adobe.com> wrote:
>
> >
> >
> > On 11/17/13 2:59 AM, "Maurice Amsellem" <ma...@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
> >
> >
>
Re: Air Stage Text Issue
Posted by Cosma Colanicchia <co...@gmail.com>.
I’d like to propose a different view on the problem.
Many native mobile components provide a separate UI strategy for display
end edit: think of single and multiple selection controls, date and time
input controls, etc. Text input controls, in native applications, have a
mixed approach: sometimes, especially on phones and in landscape mode,
provide an input area that is actually part of the soft keyboard, instead
of using the original control UI for interaction. Other times, the original
control is directly used.
I think that, for the majority of mobile applications, it would be a
perfectly reasonable tradeoff to always use a dedicated UI for editing
content. This could be done using the native soft keyboard functionalities,
if the AIR runtime does provide the required hooks. Otherwise, we could
implement a TextPopupInput control managing a popup-on-edit UI. The popup
should only take into account the soft keyboard, instead of clipping,
scrolling, occlusion, etc.
In general, I think we could provide a set of popup edit controls for
mobile, that IMO are currently missing (single selection, multiple
selection, date, time and date/time, etc).
This is not a perfect solution for mobile applications heavily focused on
text input operations (e.g. a note-taking app or a mobile word processor)
but could be a reasonable and consistent for form-based and simpler input
operations, that is the most common scenario in mobile apps.
2013/11/17 Maurice Amsellem <ma...@systar.com>
> 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:flexicious@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-Flex-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 <ah...@adobe.com> wrote:
>
> >
> >
> > On 11/17/13 2:59 AM, "Maurice Amsellem" <ma...@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
> >
> >
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
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:flexicious@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-Flex-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 <ah...@adobe.com> wrote:
>
>
> On 11/17/13 2:59 AM, "Maurice Amsellem" <ma...@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
>
>
Re: Air Stage Text Issue
Posted by "Flexicious.com" <fl...@gmail.com>.
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-Flex-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 <ah...@adobe.com> wrote:
>
>
> On 11/17/13 2:59 AM, "Maurice Amsellem" <ma...@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
>
>
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
OK, good luck.
On 11/17/13 7:54 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>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.
>
>I was referring to " the last pixel of a dropshadow of a floating
>spell-check dialog" use case that you mentioned before,
>and thought it could be easily moved one pixel above to avoid occluding
>;-).
>
>As you said, there are two causes for occluding:
>- occluding because scrolled TI is clipped.
>- and occluding by a UI component that floats above the TI.
>
>For the second case, removing the scrolling will not always prevent the
>occluding issues, and I don't have a solution to that either.
>
>For the first case, I think that forcing the clipped TI to scroll into
>view is an acceptable solution; this is e.g. what Safari does on the
>iPad.
>So removing the current scrolling issue ( StageText not scrolling) is
>worthwhile.
>
>Anyway, I really appreciate your feedback on this and will soon give a
>status on the implementation...
>
>Maurice
>
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>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.
I was referring to " the last pixel of a dropshadow of a floating spell-check dialog" use case that you mentioned before,
and thought it could be easily moved one pixel above to avoid occluding ;-).
As you said, there are two causes for occluding:
- occluding because scrolled TI is clipped.
- and occluding by a UI component that floats above the TI.
For the second case, removing the scrolling will not always prevent the occluding issues, and I don't have a solution to that either.
For the first case, I think that forcing the clipped TI to scroll into view is an acceptable solution; this is e.g. what Safari does on the iPad.
So removing the current scrolling issue ( StageText not scrolling) is worthwhile.
Anyway, I really appreciate your feedback on this and will soon give a status on the implementation...
Maurice
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
On 11/17/13 2:59 AM, "Maurice Amsellem" <ma...@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
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>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:aharui@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" <ma...@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
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
On 11/16/13 4:52 PM, "Maurice Amsellem" <ma...@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
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>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.
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.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 17 novembre 2013 01:07
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
On 11/16/13 12:19 PM, "Maurice Amsellem" <ma...@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
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
On 11/16/13 12:19 PM, "Maurice Amsellem" <ma...@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
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
DataGrid failure is fixed now, and pushed to develop. Sorry for that.
Back to Mobile TextInput:
>I can try to ask the engineer who worked on it to see if he remembers.
Yes please
>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 ?
I don't understand why this would be an issue with bitmap proxying. Can you please elaborate.
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : samedi 16 novembre 2013 19:35
À : dev@flex.apache.org
Objet : RE: Air Stage Text Issue
>But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure.
sure
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : samedi 16 novembre 2013 19:32 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue
I can try to ask the engineer who worked on it to see if he remembers, but I would guess the following:
1) There was hope that AIR would provide a solution
2) I'm not sure proxying would handle text selection.
3) I'm not sure proxying would handle partially occluded text inputs.
You're welcome to take a shot at it. Adobe generally didn't like half-baked solutions so if it there was no solution for partially-occluded text inputs it wouldn't provide a solution at all, but maybe it is worth offering a solution for folks who won't ever partially occlude their text inputs (which is probably a lot of folks).
But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure.
-Alex
On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi,
>
>I am currently working on the issue about StageTextInput not scrolling
>on
>mobile:
>https://issues.apache.org/jira/browse/FLEX-33166
>
>
>Debugging the SDK source code, it appears that "proxying" the
>StageTextInput with a bitmap is already in place (see class
>StyleableStageText).
>
>However, the proxy bitmap is shown in only very specific situations:
>- a stage animation that contains the stage text is playing (example:
>Touch "throw" animation, that happens when you *release* your finger
>after swiping )
>- popup is opened , in which case all text input below in the z-order
>are proxied to bitmaps
>
>Another rather "radical" approach, which has been suggested by some (
>DarkStone, Flexicious), would be to always display a StageText as a
>proxy bitmap when it's visible, and to show the StageText only when
>typing text via the soft keyboard.
>
>It's hard for me to believe that the Adobe SDK team went into all the
>pain of implementing the bitmap proxying, and the complex popup depth
>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>think about such a simple approach.
>So there must be something else!
>
>Some ideas come to mind:
>- memory concerns: maintaining bitmap proxies for all visible text
>inputs (and text areas), especially on high resolution displays, can be
>very costly.
>- time: maybe Flex was stopped at Adobe before this approach could be
>implemented, and TI was left in an intermediate state...
>
>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>
>Does someone know ?
>
>Maurice
>
>-----Message d'origine-----
>De : DarkStone [mailto:darkstone@163.com] Envoyé : mercredi 30 octobre
>2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text
>Issue
>
>Hi Naveen,
>
>I haven't got time to implement it yet.
>
>But I figure it out a better solution:
>
>1. Create a class named "VisualStageText" which extends
>SpriteVisualElement class and implements IEditableText interface.
>
>2. In the VisualStageText class implementation, define a private
>variable stageText:StageText, use it to implement IEditableText
>yourself, and also define a private variable snapshot:Bitmap.
>
>3. Listen for VisualStageText instance's Event.ACTIVATE,
>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>interaction relative events to detect user interactions.
>
>4. When the user is currently interacting with VisualStageText, you
>need to hide the snapshot and show the stageText:
>snapshot.parent ? removeChild(snapshot) : null;
>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>
>5. When the user is not interacting with VisualStageText, you need to
>take a snapshot of the stageText, then hide the stageText and display
>the
>snapshot:
>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>snapshot.bitmapData = bd;
>stageText.stage = null;
>addChild(snapshot);
>
>Well this is it, this is the core concept of how to do a Flex version
>StageText, you can use the VisualStageText as a MXML tag, and bind it
>to the skinpart of the spark TextInput (or TextArea)'s
>textDisplay:IEditableText.
>
>I plan to implement my VisualStageText at the end of this year, but if
>you can't wait you can do it by yourself, good luck : )
>
>
>DarkStone
>2013-10-30
>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>Hi DarkStone,
>>
>>Thank you for your post.
>>
>>Can you please share the code for the same as I am little confused on
>>how to achieve this.
>>
>>Thanks is Advance
>>
>>
>>
>>--
>>View this message in context:
>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Is
>>s ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>>list archive at Nabble.com.
>
RE: Air Stage Text Issue
Posted by Maurice Amsellem <ma...@systar.com>.
>But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure.
sure
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : samedi 16 novembre 2013 19:32
À : dev@flex.apache.org
Objet : Re: Air Stage Text Issue
I can try to ask the engineer who worked on it to see if he remembers, but I would guess the following:
1) There was hope that AIR would provide a solution
2) I'm not sure proxying would handle text selection.
3) I'm not sure proxying would handle partially occluded text inputs.
You're welcome to take a shot at it. Adobe generally didn't like half-baked solutions so if it there was no solution for partially-occluded text inputs it wouldn't provide a solution at all, but maybe it is worth offering a solution for folks who won't ever partially occlude their text inputs (which is probably a lot of folks).
But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure.
-Alex
On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi,
>
>I am currently working on the issue about StageTextInput not scrolling
>on
>mobile:
>https://issues.apache.org/jira/browse/FLEX-33166
>
>
>Debugging the SDK source code, it appears that "proxying" the
>StageTextInput with a bitmap is already in place (see class
>StyleableStageText).
>
>However, the proxy bitmap is shown in only very specific situations:
>- a stage animation that contains the stage text is playing (example:
>Touch "throw" animation, that happens when you *release* your finger
>after swiping )
>- popup is opened , in which case all text input below in the z-order
>are proxied to bitmaps
>
>Another rather "radical" approach, which has been suggested by some (
>DarkStone, Flexicious), would be to always display a StageText as a
>proxy bitmap when it's visible, and to show the StageText only when
>typing text via the soft keyboard.
>
>It's hard for me to believe that the Adobe SDK team went into all the
>pain of implementing the bitmap proxying, and the complex popup depth
>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>think about such a simple approach.
>So there must be something else!
>
>Some ideas come to mind:
>- memory concerns: maintaining bitmap proxies for all visible text
>inputs (and text areas), especially on high resolution displays, can be
>very costly.
>- time: maybe Flex was stopped at Adobe before this approach could be
>implemented, and TI was left in an intermediate state...
>
>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>
>Does someone know ?
>
>Maurice
>
>-----Message d'origine-----
>De : DarkStone [mailto:darkstone@163.com] Envoyé : mercredi 30 octobre
>2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text
>Issue
>
>Hi Naveen,
>
>I haven't got time to implement it yet.
>
>But I figure it out a better solution:
>
>1. Create a class named "VisualStageText" which extends
>SpriteVisualElement class and implements IEditableText interface.
>
>2. In the VisualStageText class implementation, define a private
>variable stageText:StageText, use it to implement IEditableText
>yourself, and also define a private variable snapshot:Bitmap.
>
>3. Listen for VisualStageText instance's Event.ACTIVATE,
>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>interaction relative events to detect user interactions.
>
>4. When the user is currently interacting with VisualStageText, you
>need to hide the snapshot and show the stageText:
>snapshot.parent ? removeChild(snapshot) : null;
>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>
>5. When the user is not interacting with VisualStageText, you need to
>take a snapshot of the stageText, then hide the stageText and display
>the
>snapshot:
>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>snapshot.bitmapData = bd;
>stageText.stage = null;
>addChild(snapshot);
>
>Well this is it, this is the core concept of how to do a Flex version
>StageText, you can use the VisualStageText as a MXML tag, and bind it
>to the skinpart of the spark TextInput (or TextArea)'s
>textDisplay:IEditableText.
>
>I plan to implement my VisualStageText at the end of this year, but if
>you can't wait you can do it by yourself, good luck : )
>
>
>DarkStone
>2013-10-30
>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>Hi DarkStone,
>>
>>Thank you for your post.
>>
>>Can you please share the code for the same as I am little confused on
>>how to achieve this.
>>
>>Thanks is Advance
>>
>>
>>
>>--
>>View this message in context:
>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Is
>>s ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>>list archive at Nabble.com.
>
Re: Air Stage Text Issue
Posted by Alex Harui <ah...@adobe.com>.
I can try to ask the engineer who worked on it to see if he remembers, but
I would guess the following:
1) There was hope that AIR would provide a solution
2) I'm not sure proxying would handle text selection.
3) I'm not sure proxying would handle partially occluded text inputs.
You're welcome to take a shot at it. Adobe generally didn't like
half-baked solutions so if it there was no solution for partially-occluded
text inputs it wouldn't provide a solution at all, but maybe it is worth
offering a solution for folks who won't ever partially occlude their text
inputs (which is probably a lot of folks).
But before you go work on that, can you look at the most recent mustella
failures? I think there is a new DataGrid failure.
-Alex
On 11/16/13 5:17 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi,
>
>I am currently working on the issue about StageTextInput not scrolling on
>mobile:
>https://issues.apache.org/jira/browse/FLEX-33166
>
>
>Debugging the SDK source code, it appears that "proxying" the
>StageTextInput with a bitmap is already in place (see class
>StyleableStageText).
>
>However, the proxy bitmap is shown in only very specific situations:
>- a stage animation that contains the stage text is playing (example:
>Touch "throw" animation, that happens when you *release* your finger
>after swiping )
>- popup is opened , in which case all text input below in the z-order are
>proxied to bitmaps
>
>Another rather "radical" approach, which has been suggested by some (
>DarkStone, Flexicious), would be to always display a StageText as a proxy
>bitmap when it's visible,
>and to show the StageText only when typing text via the soft keyboard.
>
>It's hard for me to believe that the Adobe SDK team went into all the
>pain of implementing the bitmap proxying, and the complex popup depth
>calculations (cf. StyleableStageText 3000+ lines of code) and didn't
>think about such a simple approach.
>So there must be something else!
>
>Some ideas come to mind:
>- memory concerns: maintaining bitmap proxies for all visible text inputs
>(and text areas), especially on high resolution displays, can be very
>costly.
>- time: maybe Flex was stopped at Adobe before this approach could be
>implemented, and TI was left in an intermediate state...
>
>Or maybe, they didn't see the scrolling issue... nobody is perfect.
>
>Does someone know ?
>
>Maurice
>
>-----Message d'origine-----
>De : DarkStone [mailto:darkstone@163.com]
>Envoyé : mercredi 30 octobre 2013 08:26
>À : dev@flex.apache.org
>Objet : Re:Re: Re:Air Stage Text Issue
>
>Hi Naveen,
>
>I haven't got time to implement it yet.
>
>But I figure it out a better solution:
>
>1. Create a class named "VisualStageText" which extends
>SpriteVisualElement class and implements IEditableText interface.
>
>2. In the VisualStageText class implementation, define a private variable
>stageText:StageText, use it to implement IEditableText yourself, and also
>define a private variable snapshot:Bitmap.
>
>3. Listen for VisualStageText instance's Event.ACTIVATE,
>Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other
>interaction relative events to detect user interactions.
>
>4. When the user is currently interacting with VisualStageText, you need
>to hide the snapshot and show the stageText:
>snapshot.parent ? removeChild(snapshot) : null;
>snapshot.bitmapData.dispose(); snapshot.bitmapData = null;
>stageText.stage = stage; stageText.viewPort = new Rectangle(...);
>
>5. When the user is not interacting with VisualStageText, you need to
>take a snapshot of the stageText, then hide the stageText and display the
>snapshot:
>var bd:BitmapData = new BitmapData(stageText.viewPort.width,
>stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd);
>snapshot.bitmapData = bd;
>stageText.stage = null;
>addChild(snapshot);
>
>Well this is it, this is the core concept of how to do a Flex version
>StageText, you can use the VisualStageText as a MXML tag, and bind it to
>the skinpart of the spark TextInput (or TextArea)'s
>textDisplay:IEditableText.
>
>I plan to implement my VisualStageText at the end of this year, but if
>you can't wait you can do it by yourself, good luck : )
>
>
>DarkStone
>2013-10-30
>At 2013-10-30 01:44:33,Naveen2803 <na...@gmail.com> wrote:
>>Hi DarkStone,
>>
>>Thank you for your post.
>>
>>Can you please share the code for the same as I am little confused on
>>how to achieve this.
>>
>>Thanks is Advance
>>
>>
>>
>>--
>>View this message in context:
>>http://apache-flex-development.2333347.n4.nabble.com/Air-Stage-Text-Iss
>>ue-tp30223p31670.html Sent from the Apache Flex Development mailing
>>list archive at Nabble.com.
>