To clarify, the two issues I mentioned below only
appear when compiled to SWF9 or 10.
On 4/5/2010 2: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"
>
<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]
|