Fix issue with xml error

While the @:build macro speed up development, you’re the only one in charge of the validation of the loaded XML.
and so, times to times, you have this kind of panic error

/usr/local/lib/haxe/lib/haxeui-core/git/haxe/ui/macros/ComponentMacros.hx:300: characters 37-68 : Int should be String
src/view.hx:12: lines 12-32 : Defined in this class

it means one of your components’ parameter is wrong.

but which one ?
From what I see, there is no way to find it from the error message (it’s why I call it “panic error”).

Is there another way than to uncomment component one by one and wait for error ?


Yeah, it would be nice for it to say which property / value / location. Just to make sure we are talking about the same thing, can you paste in your xml + haxe class?


I find the culprit in my case:

 <textfield id="tfPAN" width="100%" maxChars="16" restrictChars="0123456789" />

I’d like to restrict the textfield to numbers
But the XML parsing converts “0123456789” to an integer and so it crashes.

if I change it to

 <textfield id="tfPAN" width="100%" maxChars="16" restrictChars="n0123456789" />

no problem

oh, thats interesting. The xml parser tries to “guess” if the property is a number, string, float, bool… and this case it (incorrectly) guesses it as a number. Ill have to think about it. :confused:

Does restrict chars even work on native platforms??


Now that I fixed the XML issue I can confirm you restrict doesn’t work :frowning:

I’ll have to implement an onchange trick then

I looked for a native method in wxTextCtrl and there doesnt seem to be one. There does however seem to be a “Validator” class that can be used in conjunction with wxTextCtrl so that could probably be used eventually.

Oh great.
I was about to ask if there is some way to code a validator.
In my case, it’s credit card number so I was wondering how to implement the Luhn validator

Well, it would defo be possible, although hxWidgets (which are hxcpp externs for wxWidgets and haxeui-hxwidgets uses) hasnt exposed this class yet. Exposing the class is easy, the harder part would be allowing that extern class to override the Validate (wxWindow *parent) virtual function.

Ill have to have a think / play with it, but suffice to say, there is a way in wxWidgets, it just hasnt been exposed to either hxWidgets or haxeui-hxwidgets.


I was looking at TextField.hx and it seems you handled restricted through a TextFieldHelper.
but since it’s private and RestrictCharsBehaviour too, I can’t reuse it.

I tried to hack something but it crashes through an endless loop since setting .text/.value throws a CHANGE event, which I registered to add my hack

var tf:TextField = cast(, TextField);
if (tf.restrictChars == "") return;
var formated:String ="";
var ff:Array<String> = tf.text.split("");
//TODO: probably could be easier with a regex but I don't know how to
for(c in ff)
   if ( tf.restrictChars.indexOf(c) >= 0  )
      formated += c;
trace("should be "+formated);  //ok
tf.value = formated;  //endless loop crash

So this is an implementation detail of how haxeui works and how it can handle native components and multiple backends. Simply put there are two “types” of controls.

There are “composite” components in which the the internals are all handle by haxeui, and the drawing is delegated to a backend (like openfl, or kha, or html).

Then there are “native” components where the Component class is essentially a wrapper around a native component (like wxwidgets, qt, android).

This is why there are “behaviors”. For native components (like wxwidgets) the behaviors are replaced by native behaviors defined in the backend. So even though there is a RestrictCharsBehaviour, it wont be used because wx widgets is a native backend, and there fore textfield will NOT lead to a composite component, but rather a native component (wxTextField in this case).

Moreover, as you have noticed, its likely that some or most of the composite behaviors rely on that component having certain children, or properties etc. Which wouldnt be the case for native components.

Basically, the behaviors in haxeui-core are for composite components, which native platforms are not. The config for how behaviors and wrappers are created for haxeui-hxwidgets textfield can be seen here:

As you can see, the “restrictChars” behavior is replaced with “DefaultBehaviour” so, wont do anything.

Very interesting!!
I noticed also how you handle style, it was something so strange for me (CSS style to native style)

FYI, placeholder isn’t working too on OSX

Yeah, i dont think thats a “thing” on wxWidgets (maybe im wrong), this is the placeholder behaviour:

class TextCtrlPlaceholder extends HxWidgetsBehaviour {
    public override function set(value:Variant) {
        if (_component.window == null) {
    public override function get():Variant {
        return null;

ie, nothing… placeholder code for placeholder :smiley:


actually, it looks like “setHint” will work… will try it out tomorrow:

sample to reproduce restrictChars build error available on

1 Like