We really need to get this straight. Despite our API being called getTextWidth, it is not, Not, NOT, supposed to be the AS2 .textWidth property because of exactly this kind of bug. That property leaves out the gutter that is _always_ on the clip, if the clip is set to autosize. The diagram André points to is a Flash-specific diagram, which is helpful for the OL kernel implementor, but the OL user should not have to consult it. The OL user should not have to conditionally add 4 pixels to the output of getTextWidth based on the platform he is compiling to.
The contract of the kernel getTextWidth API is to return the width that would be needed to display the contained text without clipping or scrolling. This is why the swf8 kernel uses the ._width property of the clip (which always includes the gutter), and why the dhtml kernel uses the .clientWidth property of the div. If the bug is only for swf9/10, then I would say the swf9/10 kernel is not implementing the kernel contract and needs to be examined more closely. On 2010-04-05, at 10:41, Henry Minsky wrote: > That autoscrolling behavior happens when the Flash text field thinks it is > smaller than the text width. I guess the value being returned by > getTextWidth is not quite large enough. I need to do some experiments to see > what the delta is between the text width being returned and the width which > will actually cause it to stop scrolling. Andre Bargull has found a helpful > chart > http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/images/text-metrics.jpg, > which would indicate a value of 4 might be sufficient to account for the > difference between the actual graphic width of the text and the amount that > Flash thinks is needed for the proper padding at the left and right. > > > > I guess for now you could some padding e.g., > <handler name="ontext"> > this.setAttribute( 'width', this.getTextWidth() +4); > </handler> > > > > > > > > On Mon, Apr 5, 2010 at 5:53 AM, <[email protected]> wrote: > >> Thank you very much Henry, that does indeed seem to work for the most >> part. I never would have thought of that workaround. Also, there are >> still a few issues. First, the cursor behavior is not reliable (it >> disappears if positioned at the end of the text, but remains >> visible/blinking if positioned within the text). >> >> Also, using that example code below, when mouse-clicking to focus the >> <inputtext>, no matter where the click occurs in the text, the text is >> scrolled left such that the end of the text is positioned at approximately >> the 66%-of-width position, which means some portion of the beginning of the >> text is clipped. I don't want this behaviour. I have setup handlers for >> all the <onhscroll>, <onxscroll>, <scroll> events, but I see nothing >> happening when this occurs. Do you know how I can disable this "scroll-left >> on focus"?. I gather it was done as a convenience to allow some room for >> the user to enter text at the end of the element, but it is broken. >> Regardless of where the user clicks, it always scrolls the same amount to >> the left. So if the user clicks at the beginning of the text, it still >> scrolls left and then places the cursor some distance into the text. >> >> Thank you... >> >> >> On 4/5/2010 1:59 AM, Henry Minsky wrote: >> >> >> >> As a workaround, try something like the code below, to manually recompute >> the text width. I think >> this will work in both Flash and DHTML, because by the time the "ontext" >> event comes from >> the kernel, the kernel has had time to update the width. >> >> I'll check if there's a bug in JIRA already regarding resize width behavior >> for single line >> input text fields. It does seem like the LzInputText class ought to do >> this automatically >> when the text is modified and the resize flag is true. >> >> >> >> <canvas width="100%" height="80%" debug="true"> >> <debug fontsize="12"/> >> >> <inputtext name="text1" resize="true" align="center" valign="middle" >> multiline="false" fontsize="14" >> bgcolor="#cccccc" >> oninit="this.setAttribute( 'text', 'enter text here' );" > >> <handler name="ontext"> >> this.setAttribute( 'width', this.getTextWidth() ); >> </handler> >> </inputtext> >> >> </canvas> >> >> >> >> On Mon, Apr 5, 2010 at 3:38 AM, <[email protected]> wrote: >> >>> I'm a little baffled here trying to create a simple <inputtext> that >>> resizes as the user changes the text. >>> >>> Developers Guide Chapter 21 section 4.4 says the following.... >>> >>> "Setting the resize attribute on a text field will cause it to be resized >>> to fit its text content at runtime, whenever the >>> setText()<http://www.openlaszlo.org/lps4.2/docs/reference/lz.text.html#LzText.prototype.setText>method >>> is called." >>> >>> So if I set resize="true", and the user types text into the element >>> during runtime, the element size does *not* automatically resize. Am I >>> misunderstanding, or is that somewhat not-useful? What is the point of the >>> resize function then? >>> >>> So what then is the recommended way to make the <inputtext> auto resize >>> with user-entered text? Here's my attempt: >>> >>> <inputtext name="text1" resize="true" align="center" >>> valign="middle" multiline="false" fontsize="14" >>> oninit="this.setAttribute( 'text', "enter text here" );" >>>> >>> <handler name="ontext"> >>> this.setAttribute( 'text', this.text ); >>> Debug.write( "got ontext, text is now " + this.text + ", >>> width=" + this.width ); >>> </handler> >>> </inputtext> >>> >>> >>> On a guess, I tried using the "ontext" event (which is listed without >>> description in the docs). That does trigger an event on any change to the >>> text, but for some reason the width does not automatically resize, although >>> the debug output does show the changed text after each keypress. >>> >>> However, I can do the exact same setAttribute from the debug console >>> while the element still has focus, and it works as expected, resizes just >>> fine, width changes automatically. ??? >>> >>> If I might comment, it is these kind of *"it should just work, but >>> doesn't"* quirks that really throw me for a loop with OL. It seems like >>> I run into these too often. Is it just me? I usually have to sit here with >>> the debugger and experiment until I find just the right combination to get >>> something to work. And then sometimes, like the example above, it works >>> differently in runtime than it does in the debugger!! It gets really >>> frustrating. >>> >>> Thanks in advance for any advice.... >>> >> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] >> >> >> > > > -- > Henry Minsky > Software Architect > [email protected]
