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]>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] 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]> > <[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 [email protected] > > -- Henry Minsky Software Architect [email protected]
