I believe this is by design, and the way around it is to make arguments optional. You're talking about the constructors, right? @limited-advantage-32748

Yes I am

It would be nice if haxe had per-class factory methods like Dart does because then haxeui could potentially get around that problem instead allowing you to specify an interface-level constructor.

This could still be possible with haxeui and haxe, I believe the best solution is adding a macro-level feature for custom components that let a user specify a specific function to be used for framework level construction while we could continue to use our own constructors. I've definitely run into this problem a few times.

What do you think Ian?

The main reason i disallow non optional constructor args is for the xml

do you get this error if you arent using xml?

I haven't tried an xml and really don't know how to

I have gotten that error without it

oh yeah? Without xml... interesting

sounds like its something that can be fixed then

``Building HaxeUIMacroBug Running Pre-Build Command Line... cmd: "C:\HaxeToolkit\haxe/haxelib" run lime build "project.xml" windows -release -Dfdb Warning: Lime version 7.8.0 may not be compatible with OpenFL 8.9.7 (expected version 7.7.*) Use before to include a specific version C:/HaxeToolkit/haxe/lib/haxeui-core/1,1,1/haxe/ui/macros/Macros.hx:320: characters 20-35 : Not enough arguments, expected _someDumbArgumentHere:String src/AClassThatExtendsBoxAndExpectsArguments.hx:9: lines 9-17 : Defined in this class Build halted with errors.`` ``src/AClassThatExtendsBoxAndExpectsArguments.hx:9: lines 9-17 : Defined in this class`` ``C:/HaxeToolkit/haxe/lib/haxeui-core/1,1,1/haxe/ui/macros/Macros.hx:320: characters 20-35 : Not enough arguments, expected _someDumbArgumentHere:String``

What do you think of having an optionally implementable factory constructor for xml interfaces?

Instead of defaulting to new

Do you want me to submit the issue then?

@User - issue sounds good, yeah

looks like its a bug in the macro that builds the component... i presume you must be using a @:build, yeah?

I am not

oh, you arent

thats even stranger

minimal code needed was provided as well

yeah, got it... thanks

> What do you think of having an optionally implementable factory constructor for xml interfaces?

in what sense?

like

XmlConstructable<T> { function create():T }

I don't think it would really need to be anything more than a function actually, no instance would need to be instantiated

ah, its the clone function

a macro automatically creates a clone function, and that uses "new XYZ()"

it it would be easy to add params to that based on the constrcutor... the problem however is what to set them to