[Windows target] TextField support in OpenFL?

#1

I’ve installed Flash Develop, Lime and OpenFL last night, and try to add a few lines of code but no luck:

package;

import openfl.display.Sprite;
import openfl.Lib;
import openfl.text.TextField;
import openfl.filesystem.File;
import openfl.text.*;

class Main extends Sprite
{
private var tf:TextField = new TextField();

public function new() 
{
	super();
	
	this.addChild(tf);
	tf.border = tf.background = true;
	tf.width = 300;
	tf.height = 200;
	tf.x = tf.y = 10;
	tf.type = TextFieldType.INPUT;
	tf.multiline = true;
	tf.wordWrap = true;
	var fm:TextFormat = new TextFormat();
		fm.font = "Arial";
	tf.defaultTextFormat = fm;
	tf.text = "test thử xem sao";
}

}

Unicode not supported, bad text quality, with the wrong behavior. The text field even not able to select and edit. Only Flash target worked.

If I missed somethings?

#2

Could you please try editing the target drop-down to use “windows -Dlegacy”, and see how that works for you?

#3

@singmajesty, can you please explain to us how to use textfield wordWarp on html5?
there are known issues about the texfields and for what I have tried:
windows and neko targets works fine with -Dlegacy issues vanishes
flash is perfect
but with html I am at loss.

#4

I’m not sure that TextField.INPUT + wordWrap is supported in HTML5 yet. Displaying word wrapped text should work

TextField is a big subject, and one that could certainly bear more improvements. Things have been coming along, but the source is all there if someone wants to help. The goal is to merge the implementations further, so we have one good TextField for all platform targets

1 Like
#5

After few more tests, the html propblem with wordWrap happens in htmlText property, when putting more than one font tag inside the string, it’s like wordWrap is turned off and that only on html targets. others are fine.

The reason I like htmlText is because you’ve made it quite simple to change the colours or font inside the string which works on every target.

the method setTextFormat do not work quite well on html, in my case I like changing colours to some parts of my text.
and the setTextFormat works well on flash and neko -Dlegacy (where I work most of the time).
but in html and neko it’s the whole text that changes colours… too bad.

so htmlText was the answer to that which is perfect every where flash, neko, android… but as i have moved to html target, I am back to being a newbie again.

I really would love to help, but truth be told I do not understand a lot of those codes xP
@singmajesty, thank you very much for your hardwork,

#6

The design of OpenFL/Lime is very complex. I really do wish implementations were simpler, then it would make everyone’s lives easier, but apparently we have to make function call after function call after function call just to do one task. Quite unnecessary, but apparently that’s how we design game logic in the programming world.

I remember looking up how HaxeFlixel does the resizing of a game window, and it starts with FlxG.resizeGame(800, 600) which calls something in System which then calls something in ScaleMode which inherits from a different type of ScaleMode… I don’t know why people can’t just build their OpenFL app on top of Lime and just call window.resize(800, 600);

I think the major problem is that backend video game developers just develop and have little to no designing experience, so it’s all object-oriented and everything has to inherit from something else, etc.

If the underlying code of Lime wasn’t as complex as it was, I would personally contribute to amend things particularly in the TextField, since it does need improvements, particularly on native targets. But Lime is so big now that redesigning would take up too much time. I’m not saying it’s terrible, just has some design flaws, which is inherent in object-oriented design.

More languages like C please :smile: smirk

#7

The code for rendering TextField for HTML5 canvas is here:

https://github.com/openfl/openfl/blob/master/openfl/_internal/renderer/canvas/CanvasTextField.hx

Let me know if you think we could make this architecturally simpler.

I want to do something that makes things like detecting wordWrap shared between all renderers, there’s no reason it should be canvas-specific. For now, though, you can see here where it calculates wordWrap, I’m sure there’s a way to do it for htmlText as well

#8

I think its arguably easier to understand than the legacy C++ TextField code :slight_smile:

#9

I’m looking at a workaround for the current “non-input” TextField in native targets. While the TextField is focused, I’m just listening on the KEY_UP event and appending the text appropriately. That’s with no caret, you can probably implement it better than I can…