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]
