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?
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.
Does restrict chars even work on native platforms??
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( e.target, 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.
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) {
super.set(value);
if (_component.window == null) {
return;
}
}
public override function get():Variant {
return null;
}
}
