You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2016/03/01 03:37:27 UTC
Re: Error #2006: The supplied index is out of bounds
On Mon, Feb 29, 2016 at 1:40 PM, Alex Harui <ah...@adobe.com> wrote:
> Om,
>
> Why stageWidth/stageHeight and not 8192? And won't that just stack the
> StageTexts at that point? I haven't looked to deeply at this issue, but I
> thought it was about scrolling a long document. Let's say you want to
> caption a list of pictures that are 1000 pixels in height, the StageText
> where you want to edit the caption is 20 pixels in height and you 10 of
> them. In theory it should be ok to place StageTexts at y=10000, otherwise
> you won't get smooth scrolling. If you force it back to 8192 or
> stageHeight it will overlap something else.
>
> Without thinking too much about it, some sort of virtual layout would
> probably be required, like the MX lists do.
>
> Of course, I could be wrong...
>
This piece of code is calculating the StageText object's global viewport
rectangle wrt stage co-ordinates. Viewport is defined as: 'The area on the
stage in which the StageText object is displayed. The default is the zero
rect.'
This viewport is used to capture a bitmap of the stagetext and replace the
image the place of the stagetext object while scrolling. So, any viewport
bounds that is outside the stage can be safely clipped to the bounds of the
stage.
Although you are right, there might be a more efficient way of doing all
this.
On that topic, there was another edgecase where setting the height of a
TextInput to 10000 caused the same issue. I have gone ahead and added the
same checks to the viewport rectangle's width and height.
New commit here:
https://github.com/apache/flex-sdk/commit/fd7de9f724219bff2b3096a8057fc830ccf07391
Thanks,
Om
>
> -Alex
>
> On 2/29/16, 1:21 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >Okay, I've checked in a fix. If someone can review it, it would be great:
> >
> >
> https://github.com/apache/flex-sdk/commit/f14dc1431c1914a5e1fef6c77b67b23b
> >9c41a7fd
> >
> >You can monkey patch your SDK with this fix, or get the Flex Nightly build
> >and test out the fix.
> >
> >Thanks,
> >Om
> >
> >On Mon, Feb 29, 2016 at 6:30 AM, Philip Medlam <ph...@gmail.com>
> >wrote:
> >
> >> For information,
> >> the workaround in the bug report does indeed work.
> >>
> >> Phil.
> >>
> >> On Mon, Feb 29, 2016 at 6:30 AM, npem <ph...@gmail.com> wrote:
> >>
> >> > OK thanks for your efforts.
> >> >
> >> > Hope there is a fix, but will look at the workaround suggested in the
> >>bug
> >> > report.
> >> >
> >> > Phil.
> >> >
> >> > On Mon, Feb 29, 2016 at 12:19 AM, OmPrakash Muppirala [via Apache Flex
> >> > Users] <ml...@n4.nabble.com> wrote:
> >> >
> >> > > Looks like this issue has been reported already:
> >> > > https://issues.apache.org/jira/browse/FLEX-34391
> >> > >
> >> > > I'm trying to check in a fix for this.
> >> > >
> >> > > Thanks,
> >> > > Om
> >> > >
> >> > > On Sun, Feb 28, 2016 at 9:12 AM, OmPrakash Muppirala <[hidden email]
> >> > > <http:///user/SendEmail.jtp?type=node&node=12079&i=0>>
> >> > > wrote:
> >> > >
> >> > > > Please file a bug with small test case app that reproduces this
> >> issue.
> >> > > I
> >> > > > will take a look at this asap.
> >> > > >
> >> > > > Also note which devices this bug occurs in.
> >> > > >
> >> > > > Thanks,
> >> > > > Om
> >> > > > On Feb 28, 2016 9:09 AM, "npem" <[hidden email]
> >> > > <http:///user/SendEmail.jtp?type=node&node=12079&i=1>> wrote:
> >> > > >
> >> > > >> Thanks for the suggestion, unfortunately, this has the same
> >>problem.
> >> > > >>
> >> > > >> Out of interest, if I use an tablet, rather than a phone, the
> >> problem
> >> > > does
> >> > > >> not occur.
> >> > > >>
> >> > > >> Obviously it's "Out of Bounds" depends upon the screen height.
> >> > > >>
> >> > > >> Grrrr
> >> > > >>
> >> > > >> Phil.
> >> > > >>
> >> > > >> On Sun, Feb 28, 2016 at 3:23 PM, piotrz [via Apache Flex Users] <
> >> > > >> [hidden email] <http://
> >> /user/SendEmail.jtp?type=node&node=12079&i=2>>
> >> > > wrote:
> >> > > >>
> >> > > >> > Hi Phil,
> >> > > >> >
> >> > > >> > Maybe more suitable solution would be use DataGroup with some
> >> custom
> >> > > >> Item
> >> > > >> > Renderers.
> >> > > >> >
> >> > > >> > Piotr
> >> > > >> > Apache Flex PMC
> >> > > >> > [hidden email] <http://
> >> > /user/SendEmail.jtp?type=node&node=12079&i=3>
> >> > > >> >
> >> > > >> >
> >> > > >> > ------------------------------
> >> > > >> > If you reply to this email, your message will be added to the
> >> > > discussion
> >> > > >> > below:
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/Error-2006-The-supplied-in
> >>dex-is-out-of-bounds-tp12068p12076.html
> >> > > >> > To unsubscribe from Error #2006: The supplied index is out of
> >> > bounds,
> >> > > >> click
> >> > > >> > here
> >> > > >> > <
> >> > > >> >
> >> > > >> > .
> >> > > >> > NAML
> >> > > >> > <
> >> > > >>
> >> > >
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/template/NamlServlet.jtp?m
> >>acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.
> >>namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble
> >>.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%
> >>3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21na
> >>bble%3Aemail.naml
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Philip Medlam
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> View this message in context:
> >> > > >>
> >> > >
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/Error-2006-The-supplied-in
> >>dex-is-out-of-bounds-tp12068p12077.html
> >> > > >> Sent from the Apache Flex Users mailing list archive at
> >>Nabble.com.
> >> > > >>
> >> > > >
> >> > >
> >> > >
> >> > > ------------------------------
> >> > > If you reply to this email, your message will be added to the
> >> discussion
> >> > > below:
> >> > >
> >> > >
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/Error-2006-The-supplied-in
> >>dex-is-out-of-bounds-tp12068p12079.html
> >> > > To unsubscribe from Error #2006: The supplied index is out of
> >>bounds,
> >> > click
> >> > > here
> >> > > <
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/template/NamlServlet.jtp?m
> >>acro=unsubscribe_by_code&node=12068&code=cGhpbGlwLm1lZGxhbUBnbWFpbC5jb218
> >>MTIwNjh8OTcwMjY1NTIz
> >> > >
> >> > > .
> >> > > NAML
> >> > > <
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/template/NamlServlet.jtp?m
> >>acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.
> >>namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble
> >>.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%
> >>3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21na
> >>bble%3Aemail.naml
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Philip Medlam
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context:
> >> >
> >>
> >>
> http://apache-flex-users.2333346.n4.nabble.com/Error-2006-The-supplied-in
> >>dex-is-out-of-bounds-tp12068p12081.html
> >> > Sent from the Apache Flex Users mailing list archive at Nabble.com.
> >> >
> >>
> >>
> >>
> >> --
> >> Philip Medlam
> >>
>
>
Re: Error #2006: The supplied index is out of bounds
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Mar 1, 2016 at 7:02 AM, Clint M <cm...@gmail.com> 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 <bi...@gmail.com>
> 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 <
> bigosmallm@gmail.com
> > >
> > wrote:
> >
> >
>
Re: Error #2006: The supplied index is out of bounds
Posted by Alex Harui <ah...@adobe.com>.
I agree we shouldn’t resize if multiline=true.
IMO it would be great to have Clint work on this.
I think the only thing not covered is what conditions we "give up" on. If
I understand correctly, it would be any multiline StageText greater than
16384 in width/height, or just 8192?
I could be wrong, but I think for multiline=false you could resize, but if
you don't want to bother handling that case that's fine with me.
And did we agree that if we hit these extreme cases we throw an error? Or
just output something to trace()?
Thanks,
-Alex
On 3/2/16, 6:36 AM, "Clint M" <cm...@gmail.com> wrote:
>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 = 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 <bi...@gmail.com>
>wrote:
>
>> On Tue, Mar 1, 2016 at 1:01 PM, OmPrakash Muppirala
>><bi...@gmail.com>
>> wrote:
>>
>> > On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <ah...@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,
>>have
>> >> 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
>>move
>> >> the right side, so if you change .x, you have to change .width (but
>>not
>> >> vice-versa). The clipping code should just visit each of the four
>>sides
>> >> to make them fit within the allowed range and make adjustments
>>without
>> >> moving the opposite side.
>> >>
>> >> So, something like:
>> >>
>> >> if (x < -8192) {
>> >> var delta = -8192 - x;
>> >> x += delta;
>> >> width -= delta;
>> >> }
>> >> if (x + width > 8192) {
>> >> var delta = x + width - 8192;
>> >> width -= 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
>>causes
>> > 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
>>viewport
>> 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" <cm...@gmail.com> 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?
>> >> >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.
>> >> >
>> >> >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.
>> >> >
>> >> >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
>>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
>> >> >><bigosmallm@gmail.com
>> >> >> >
>> >> >> wrote:
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>>
Re: Error #2006: The supplied index is out of bounds
Posted by Clint M <cm...@gmail.com>.
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 = 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 <bi...@gmail.com>
wrote:
> On Tue, Mar 1, 2016 at 1:01 PM, OmPrakash Muppirala <bi...@gmail.com>
> wrote:
>
> > On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <ah...@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, have
> >> 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 move
> >> the right side, so if you change .x, you have to change .width (but not
> >> vice-versa). The clipping code should just visit each of the four sides
> >> to make them fit within the allowed range and make adjustments without
> >> moving the opposite side.
> >>
> >> So, something like:
> >>
> >> if (x < -8192) {
> >> var delta = -8192 - x;
> >> x += delta;
> >> width -= delta;
> >> }
> >> if (x + width > 8192) {
> >> var delta = x + width - 8192;
> >> width -= 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 causes
> > 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 viewport
> 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" <cm...@gmail.com> 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?
> >> >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.
> >> >
> >> >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.
> >> >
> >> >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 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
> >> >><bigosmallm@gmail.com
> >> >> >
> >> >> wrote:
> >> >>
> >> >>
> >>
> >>
> >
>
Re: Error #2006: The supplied index is out of bounds
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Mar 1, 2016 at 1:01 PM, OmPrakash Muppirala <bi...@gmail.com>
wrote:
> On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <ah...@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, have
>> 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 move
>> the right side, so if you change .x, you have to change .width (but not
>> vice-versa). The clipping code should just visit each of the four sides
>> to make them fit within the allowed range and make adjustments without
>> moving the opposite side.
>>
>> So, something like:
>>
>> if (x < -8192) {
>> var delta = -8192 - x;
>> x += delta;
>> width -= delta;
>> }
>> if (x + width > 8192) {
>> var delta = x + width - 8192;
>> width -= 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 causes
> 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 viewport
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" <cm...@gmail.com> 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?
>> >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.
>> >
>> >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.
>> >
>> >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 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
>> >><bigosmallm@gmail.com
>> >> >
>> >> wrote:
>> >>
>> >>
>>
>>
>
Re: Error #2006: The supplied index is out of bounds
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Mar 1, 2016 at 8:33 AM, Alex Harui <ah...@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, have
> 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 move
> the right side, so if you change .x, you have to change .width (but not
> vice-versa). The clipping code should just visit each of the four sides
> to make them fit within the allowed range and make adjustments without
> moving the opposite side.
>
> So, something like:
>
> if (x < -8192) {
> var delta = -8192 - x;
> x += delta;
> width -= delta;
> }
> if (x + width > 8192) {
> var delta = x + width - 8192;
> width -= 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 causes 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.
Thanks,
Om
> -Alex
>
> On 3/1/16, 7:02 AM, "Clint M" <cm...@gmail.com> 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?
> >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.
> >
> >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.
> >
> >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 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
> >><bigosmallm@gmail.com
> >> >
> >> wrote:
> >>
> >>
>
>
Re: Error #2006: The supplied index is out of bounds
Posted by Alex Harui <ah...@adobe.com>.
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, have
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 move
the right side, so if you change .x, you have to change .width (but not
vice-versa). The clipping code should just visit each of the four sides
to make them fit within the allowed range and make adjustments without
moving the opposite side.
So, something like:
if (x < -8192) {
var delta = -8192 - x;
x += delta;
width -= delta;
}
if (x + width > 8192) {
var delta = x + width - 8192;
width -= delta;
}
Of course, I could definitely be wrong...
-Alex
On 3/1/16, 7:02 AM, "Clint M" <cm...@gmail.com> 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?
>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.
>
>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.
>
>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 <bi...@gmail.com>
>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
>><bigosmallm@gmail.com
>> >
>> wrote:
>>
>>
Re: Error #2006: The supplied index is out of bounds
Posted by Clint M <cm...@gmail.com>.
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?
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.
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.
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 <bi...@gmail.com>
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 <bigosmallm@gmail.com
> >
> wrote:
>
>
Re: Error #2006: The supplied index is out of bounds
Posted by OmPrakash Muppirala <bi...@gmail.com>.
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 <bi...@gmail.com>
wrote:
> You are right. There is more to this. Let me take a look at the math
> again...
>
> Thanks,
> Om
>
> On Mon, Feb 29, 2016 at 9:07 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 2/29/16, 6:37 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
>> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>>
>> >
>> >This piece of code is calculating the StageText object's global viewport
>> >rectangle wrt stage co-ordinates. Viewport is defined as: 'The area on
>> >the
>> >stage in which the StageText object is displayed. The default is the zero
>> >rect.'
>> >
>> >This viewport is used to capture a bitmap of the stagetext and replace
>> the
>> >image the place of the stagetext object while scrolling. So, any
>> viewport
>> >bounds that is outside the stage can be safely clipped to the bounds of
>> >the
>> >stage.
>>
>> I don't know this code at all, but isn't the goal to make sure no part of
>> the viewport extends out past 8192 pixels?
>> It seems to me that if the globalRect.x was -1000 and width was 500, this
>> change would set globalRect.x = 0 and thus set the viewport to 500 visible
>> pixels.
>>
>> IOW, by setting globalRect.x, you are moving the left edge of the viewport
>> to either the right edge of the stage or the left edge of the stage.
>> Moving it to the left edge of the viewport to the left edge of the stage
>> results in visible pixels. Did you intend to move the right edge of the
>> viewport to the left edge of the stage when the StageText is off-screen to
>> the left?
>>
>> Of course, I could be wrong again...
>>
>> -Alex
>>
>>
>
Re: Error #2006: The supplied index is out of bounds
Posted by OmPrakash Muppirala <bi...@gmail.com>.
You are right. There is more to this. Let me take a look at the math
again...
Thanks,
Om
On Mon, Feb 29, 2016 at 9:07 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 2/29/16, 6:37 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
> >
> >This piece of code is calculating the StageText object's global viewport
> >rectangle wrt stage co-ordinates. Viewport is defined as: 'The area on
> >the
> >stage in which the StageText object is displayed. The default is the zero
> >rect.'
> >
> >This viewport is used to capture a bitmap of the stagetext and replace the
> >image the place of the stagetext object while scrolling. So, any viewport
> >bounds that is outside the stage can be safely clipped to the bounds of
> >the
> >stage.
>
> I don't know this code at all, but isn't the goal to make sure no part of
> the viewport extends out past 8192 pixels?
> It seems to me that if the globalRect.x was -1000 and width was 500, this
> change would set globalRect.x = 0 and thus set the viewport to 500 visible
> pixels.
>
> IOW, by setting globalRect.x, you are moving the left edge of the viewport
> to either the right edge of the stage or the left edge of the stage.
> Moving it to the left edge of the viewport to the left edge of the stage
> results in visible pixels. Did you intend to move the right edge of the
> viewport to the left edge of the stage when the StageText is off-screen to
> the left?
>
> Of course, I could be wrong again...
>
> -Alex
>
>
Re: Error #2006: The supplied index is out of bounds
Posted by Alex Harui <ah...@adobe.com>.
On 2/29/16, 6:37 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
>This piece of code is calculating the StageText object's global viewport
>rectangle wrt stage co-ordinates. Viewport is defined as: 'The area on
>the
>stage in which the StageText object is displayed. The default is the zero
>rect.'
>
>This viewport is used to capture a bitmap of the stagetext and replace the
>image the place of the stagetext object while scrolling. So, any viewport
>bounds that is outside the stage can be safely clipped to the bounds of
>the
>stage.
I don't know this code at all, but isn't the goal to make sure no part of
the viewport extends out past 8192 pixels?
It seems to me that if the globalRect.x was -1000 and width was 500, this
change would set globalRect.x = 0 and thus set the viewport to 500 visible
pixels.
IOW, by setting globalRect.x, you are moving the left edge of the viewport
to either the right edge of the stage or the left edge of the stage.
Moving it to the left edge of the viewport to the left edge of the stage
results in visible pixels. Did you intend to move the right edge of the
viewport to the left edge of the stage when the StageText is off-screen to
the left?
Of course, I could be wrong again...
-Alex