On Tue, Mar 1, 2016 at 7:02 AM, Clint M <[email protected]> wrote: > Well the key is… If you think about this in the _global_ (stage) coordinate > space… anything outside the bounds of 0,0,stage.width,stage,height won't be > viewable to anyone so it should be safe in all cases to just position the > StageText outside the viewable stage area and leave it there until some > part of it is viewable. > > If you're unable to position the StageText off the stage because it's too > big. Raise an error about the limits. > > The math for the edge cases is most likely that the StageText Rect is > contained within the Rect that makes up the limits. > > So: > x > -8192 && x + width < 8192 > y > -8192 && y + height < 8192 > > However… I feel like the control is misbehaving. > I think one of the goals of this control is to show a proxied bitmap > instead of the actual StageText itself. > So why does it create a StageText at the correct x,y at all? >
Actually what's happening is that a real StageText object is created at the given viewport when it is in focus. When it is out of focus, it is replaced by a bitmap proxy. > To generate the bitmap we can just have a single StageText off the edge of > the stage. > And then in the case of edit make a new one and potentially have one more > for the case of a focus change for a total of 3 instances of StageText > although I think I could get away with just 2 instances it might actually > solve a keyboard activate/deactivate bug I'm looking at as well. > StageText uses native text objects (iOS and Android) so that there could be better soft keyboard integration. Which is why when the textinput control has focus, we need to show a real StageText object. > > I intend to come back to this control to see if I can make it work the way > I describe because I've been trying to use it as is for the past few weeks > and failed. > That would be very welcome :-) Thanks, Om > > There's also a bug with focus management and the way scroller's > softKeyboardActivate handler is trying to ensure that the control is in the > viewable area before ScrollableStageText calls assignFocus. > > > > On Tue, Mar 1, 2016 at 2:28 AM, OmPrakash Muppirala <[email protected]> > wrote: > > > Hmm, I'm not sure if there is a good solution for this. Here are the > > scenarios which could trigger this behavior: > > > > <s:TextInput x="0" *y="10000"* width="100" height="100" text="Hello"/> > > <s:TextInput *x="10000" *y="0" width="100" height="100" text="Hello"/> > > <s:TextInput x="0" y="0"* width="10000" *height="100" text="Hello"/> > > <s:TextInput x="0" y="0" width="100" *height="10000"* text="Hello"/> > > > > The StageText.viewPort has a hard limit of -8192 to 8191 for its x and y > > values. > > > > Is there a good way to solve this for for all cases? > > > > Thanks, > > Om > > > > On Tue, Mar 1, 2016 at 12:10 AM, OmPrakash Muppirala < > [email protected] > > > > > wrote: > > > > >
