So, what happens, when you have set an inputtext element to display HTML and 
the user edits the text?  How does the editing interact with the (essentially 
invisible) markup?

On 2010-04-09, at 14:03, André Bargull wrote:

> (I've changed the mail's subject back to the original title)
> 
> 
> As stated earlier [1], sometimes it is useful to have HTML capability for 
> inputtext.
> 
> [1] http://www.openlaszlo.org/pipermail/laszlo-dev/2010-March/022618.html
> 
> 
> On 4/9/2010 7:35 PM, Henry Minsky wrote:
>> oh yes, you're right, I guess we never did that.
>> 
>> If someone wants to style an input field, they can set the font
>> size/style on an input text field without calling setHTML. But if there
>> are style changes in the text
>> it's just going to make a mess when they start editing it.
>> 
>> I notice that we have a capabilities for this feature, which is disabled for
>> DHTML, maybe we should should disable it for  swf also, so people get
>> a warning in the debugger, and don't expect it to do anything useful.
>> 
>> 
>> 
>> 
>> On Fri, Apr 9, 2010 at 12:59 PM, André Bargull <[email protected]
>> <mailto:[email protected]>> wrote:
>> 
>>    "setHTML(..)" is only defined on lz.inputtext. There is no
>>    corresponding method for lz.text, is it? See LPP-6617
>> 
>> 
>>    On 4/9/2010 6:35 PM, [email protected]
>>    <mailto:[email protected]> wrote:
>>>    Hi Roger,
>>> 
>>>    The inputtext class doesn't support HTML formatting in any useful way 
>>> right
>>>    now. It inherits the
>>>    setHTML flag from lz.text, but the behavior is not well defined when you
>>>    start entering text.
>>> 
>>>    There is a rich text editor component that is specific to Flash 8, in the
>>>    incubator/rich-text directory,
>>>    but it works by doing low level calls to the Flash TextField and 
>>> TextFormat
>>>    objects directly.
>>> 
>>>    That component could probably be made to work in swf910 with some effort,
>>>    but it's a somewhat difficult
>>>    task, because the code pokes directly into the LzSprite object, and that
>>>    implementation has diverged
>>>    somewhat from swf8 to swf10.
>>> 
>>>    We're looking at the design of an updated text class that can take 
>>> advantage
>>>    of some of the
>>>    powerful features of Flash 10's text engine. The challenge will be to see
>>>    how to expose these
>>>    new features and also try to have as much cross-platform compatibility as
>>>    possible with the
>>>    DHTML runtime.
>>> 
>>> 
>>> 
>>>    On Fri, Apr 9, 2010 at 11:29 AM, Roger Yarrow<[email protected]>  
>>> <mailto:[email protected]>  wrote:
>>> 
>>> 
>>>>    >  This is occurring in OL 4.7.1 swf9/10.  I searched JIRA for a bug but
>>>>    >  couldn't seem to find a match for this situation.  Are users 
>>>> supposed to
>>>>    >  just enter bugs directly into JIRA or post here first?:)
>>>>    >
>>>>    >  The issue is that inputtext, once clicked or selected, gets all 
>>>> screwy with
>>>>    >  drawing HTML.  Once clicked/selected, all text is rendered 
>>>> improperly and
>>>>    >  cannot be recovered -- meaning it is always drawn wrong no matter 
>>>> how many
>>>>    >  times you set the text.
>>>>    >
>>>>    >  Run the test program.  Just click each button back and forth as many 
>>>> times
>>>>    >  as you want and the HTML will render properly.  Next, click inside 
>>>> the
>>>>    >  inputtext (focus) and/or select text within it.  Then click one of 
>>>> the
>>>>    >  buttons -- when the text updates, ALL the text will forever be 
>>>> displayed
>>>>    >  underlined or bolded depending upon which tag was in use at the time 
>>>> of the
>>>>    >  click.  So, if you click Bold and then select from the inputtext, 
>>>> click
>>>>    >  Underline, and all your text is bolded.  Reload the app, perform the 
>>>> same
>>>>    >  feat on Underline, and all your text will forever be underlined.
>>>>    >
>>>>    >  If I set the inputtext selectable="false"  the problem still occurs. 
>>>>  You
>>>>    >  click on the text, it selects it ALL (which I think is another bug?) 
>>>> and
>>>>    >  then the HTML rendering behavior appears.
>>>>    >
>>>>    >  <canvas width="100%"   debug="true"  height="560"  >
>>>>    >  <simplelayout axis="y"  spacing="10"/>
>>>>    >  <button>Bold
>>>>    >       <handler name="onclick">
>>>>    >           <![CDATA[
>>>>    >               test.setAttribute('text','<b>Here is 
>>>> bold<//b><br//><br/>And this
>>>>    >  should be plaintext<br/><br/><b>And bold again</b>');
>>>>    >           ]]>
>>>>    >       </handler>
>>>>    >  </button>
>>>>    >  <button>Underlined
>>>>    >       <handler name="onclick">
>>>>    >           <![CDATA[
>>>>    >               test.setAttribute('text','<a href="#"><u><font
>>>>    >  color="#0000ff">Here is a hyperlink<//font><//u></a><br//><br//>And 
>>>> this should
>>>>    >  be plaintext');
>>>>    >           ]]>
>>>>    >       </handler>
>>>>    >  </button>
>>>>    >  <inputtext width="300"  height="200"  id="test"  multiline="true"
>>>>    >  oninit="this.setHTML(true)"/>
>>>>    >  </canvas>
>>>>    >
>>>> 
>>>    -- Henry Minsky Software Architect [email protected]
>>>    <mailto:[email protected]>
>> 
>> 
>> 
>> 
>> --
>> Henry Minsky
>> Software Architect
>> [email protected] <mailto:[email protected]>
>> 
>> 


Reply via email to