Mailing-List: contact users-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@flex.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CACK5iZdyjaf1ZbseiL-iYjJ7iUqGLNZwLPbmeDi63+qqroYEkw@mail.gmail.com>
References: <1456577474458-12068.post@n4.nabble.com>
	<CAPbpUqF-Lj-YWwF1oEQLra4TKRC6iLgM2wnjXVzRa+rVQmCP7g@mail.gmail.com>
	<CAFuySW1xvL2x2nVsO2hCd9MtS2n=t=hV=41fC4fuLoE8LeJnZg@mail.gmail.com>
	<CAFuySW0emMRvw17+rbTydBHjfwVtSyhHZF=sngo-Do-L4oBk9w@mail.gmail.com>
	<1456672997481-12076.post@n4.nabble.com>
	<CAFuySW0y_zdvU1ZUhPdMYJOBZzLWRNRdgR=aEjs2++cuEPiS1Q@mail.gmail.com>
	<CACK5iZfNRpz=jG6dTXuzv70tYn6epr+wS899x5NCxy5n4evg5Q@mail.gmail.com>
	<CACK5iZc-Z2ZMyCoyWBjpE+vf+iJFBCU-e_69ycVMYtssBpNz+w@mail.gmail.com>
	<CAFuySW2FtHYDsoPRhnR11FzgM5M9aDZWNtxd30SN1PEWwjLNGw@mail.gmail.com>
	<CAFuySW0GS9c0g-3ChAsmuj81sYUph8KO3uJar3Oh1Gdn+E0f8w@mail.gmail.com>
	<CACK5iZdzo099XnDAgXzaFbrpiYBuyDWT9uMK66kdm+2foazr7w@mail.gmail.com>
	<D2F9F7B1.63FCF%aharui@adobe.com>
	<CACK5iZfq-UNf0CFBmvMjzqzPqg88gNHZwhsM+7dh5FquZE4-NA@mail.gmail.com>
	<D2FA6176.64027%aharui@adobe.com>
	<CACK5iZcHEqhyXrqv3sGNNj13NQjiRm8cchQ3w62GsVFu4dSYfQ@mail.gmail.com>
	<CACK5iZe2tJLBo9pSfY+8BwJBQuc_seqYXgRbAZk4DERei5sXVA@mail.gmail.com>
	<CAPbpUqF+5k_j1yJm2M_fBmp3F_S74HYOu3m_E3+O21zA1g1yFA@mail.gmail.com>
	<D2FB0257.640B9%aharui@adobe.com>
	<CACK5iZc5KpFW7njOXoZ-v2wMnoHA91EF8Dh3Eu-wYP2zg4AkgA@mail.gmail.com>
	<CACK5iZdyjaf1ZbseiL-iYjJ7iUqGLNZwLPbmeDi63+qqroYEkw@mail.gmail.com>
Date: Wed, 2 Mar 2016 06:36:22 -0800
Message-ID: 
 <CAPbpUqGvtxUn0ih2jXULi=tPx2_3JaPYwT08sTJ2rB0R-o1gEg@mail.gmail.com>
Subject: Re: Error #2006: The supplied index is out of bounds
From: Clint M <cmodien@gmail.com>
To: users@flex.apache.org
Content-Type: multipart/alternative; boundary=001a1141e14e4ef4d2052d11ce9a

--001a1141e14e4ef4d2052d11ce9a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with Om that we shouldn't be resizing them. If they're outside the
bounds because of size it must be an absurdly large text based control and
I think an error is appropriate to let the programmer know he's made an
error.

This control only uses these stageTexts to create bitmaps so it doesn't
matter where they are in the global coordinate space. It only matters when
a user clicks on the control and puts it in an edit state that the
stageText needs to be positioned correctly over the Flex based component.

Om, the pattern for this control should be similar to the pattern for the
sfly page renderer when we had a single renderer off the edge of the stage
that generated bitmaps that we reused.

ScrollableStageText is using a StageTextPool and creating one StageText for
each flex based ScrollableStageText. This creates a 1 - 1 mapping of
StageTexts to ScrollableStageText instances. (i.e.
100 ScrollableStageTexts =3D 100 StageTexts). It then tries to maintain the
StageText's position over the ScrollableStageText
instance using updateViewport()

I think we can get away with 1 or 2 or maybe 3 StageText instances total
for any Flex app that uses ScrollableStageText.

One for making bitmaps positioned just off the stages viewable area.
One for editing that's hidden until a control requests an edit state.
Maybe one for focus change, but I'm not sure this is required yet as I'd
like to reuse the control used for editing and might actually fix a
focusManager based softKeyboard activation/deactivation bug I'm also
looking at.

In the case of a VGroup with 200 TextInputs that are 20px high and 25px
apart (8200 px tall) there would still only be 3 StageText instances.

This seems like it would be a better fix for the bug in question.

Again I'm happy to make these changes and run them through a QA cycle here
on my current contract. I just need a week or so to get to it.


On Tue, Mar 1, 2016 at 2:46 PM, OmPrakash Muppirala <bigosmallm@gmail.com>
wrote:

> On Tue, Mar 1, 2016 at 1:01 PM, OmPrakash Muppirala <bigosmallm@gmail.com=
>
> wrote:
>
> > On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <aharui@adobe.com> wrote:
> >
> >> Hmm.  I may still be misunderstanding, but I thought this was a basic
> >> clipping issue.  So Clint is right about the goal of the math, but I
> think
> >> it doesn't matter if the StageText is on the visible portion of the
> screen
> >> or not.  For example, a very wide StageText could start offscreen, hav=
e
> >> some of it on screen and more of it offscreen as long as no part of it
> >> goes out past -8192 or +8192.
> >>
> >> If that's true, then I think the code has to recognize that changing
> the x
> >> property MOVES the StageText's right side.  IMO, you don't want to mov=
e
> >> the right side, so if you change .x, you have to change .width (but no=
t
> >> vice-versa).  The clipping code should just visit each of the four sid=
es
> >> to make them fit within the allowed range and make adjustments without
> >> moving the opposite side.
> >>
> >> So, something like:
> >>
> >> if (x < -8192) {
> >>   var delta =3D -8192 - x;
> >>   x +=3D delta;
> >>   width -=3D delta;
> >> }
> >> if (x + width > 8192) {
> >>   var delta =3D x + width - 8192;
> >>   width -=3D delta;
> >> }
> >>
> >> Of course, I could definitely be wrong...
> >>
> >>
> > The problem is if we change the StageText object's width, it will
> > potentially affect the text that is getting rendered.  A smaller width
> > means that a wrap occurs earlier in the body of text.
> >
> > That is the crux of the problem.  If the x or y of the stagetext is
> > outside the allowed bounds, we can always move it without affecting the
> > text.  When the width or height is outside the bounds (which also cause=
s
> > the ViewPort rectangle to go outside the allowed bounds) we will have
> this
> > issue no matter what.
> >
> > I guess, we just need to throw an error in this case.  I dont think it =
is
> > a common scenario to have such a large TextInput control.
> >
> >
> There's also the case where a combination of x + width causes the viewpor=
t
> bounds to exceed the 8192 threshold.  I am not sure how we would handle
> this case.
>
>
>
> > Thanks,
> > Om
> >
> >
> >> -Alex
> >>
> >> On 3/1/16, 7:02 AM, "Clint M" <cmodien@gmail.com> wrote:
> >>
> >> >Well the key is=E2=80=A6 If you think about this in the _global_ (sta=
ge)
> >> >coordinate
> >> >space=E2=80=A6 anything outside the bounds of 0,0,stage.width,stage,h=
eight
> 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 so=
me
> >> >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=E2=80=A6 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?
> >> >To generate the bitmap we can just have a single StageText off the ed=
ge
> >> 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 StageTex=
t
> >> >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.
> >> >
> >> >I intend to come back to this control to see if I can make it work th=
e
> >> way
> >> >I describe because I've been trying to use it as is for the past few
> >> weeks
> >> >and failed.
> >> >
> >> >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 <
> >> bigosmallm@gmail.com>
> >> >wrote:
> >> >
> >> >> Hmm, I'm not sure if there is a good solution for this.  Here are t=
he
> >> >> scenarios which could trigger this behavior:
> >> >>
> >> >> <s:TextInput x=3D"0" *y=3D"10000"* width=3D"100" height=3D"100"
> text=3D"Hello"/>
> >> >> <s:TextInput *x=3D"10000" *y=3D"0" width=3D"100" height=3D"100"
> text=3D"Hello"/>
> >> >> <s:TextInput x=3D"0" y=3D"0"* width=3D"10000" *height=3D"100" text=
=3D"Hello"/>
> >> >> <s:TextInput x=3D"0" y=3D"0" width=3D"100" *height=3D"10000"* text=
=3D"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
> >> >><bigosmallm@gmail.com
> >> >> >
> >> >> wrote:
> >> >>
> >> >>
> >>
> >>
> >
>

--001a1141e14e4ef4d2052d11ce9a--