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"
            >
            <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() 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" 
                  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]


Reply via email to