and that means you need to create an instance of it (im sure instance is the wrong word here)

and that means it will end up in the final output... haxeui used to accidently do this

now only the components that are used are in the output... well, mostly

but for the xsd stuff you'd want all components to be in the .xsd, but NOT in the project output

ohh, I see, ofc, I wasn't thinking about the part that, in the minute you use it in the macro, the compiler throws it in the final output, yeah, silly me 😅 yeah, that part will be tricky indeed

im wondering if the best way would be to have some seperate .hxml file, or maybe even a generated .hxml file, that sets some flags (including --no-output), and the haxeui macros can invoke that

so basically, the haxeui macros invoking the haxe compiler to generated an .xsd as part of the first build... what can possibly go wrong! The language server already hates haxeui it seems :/

indeed 😆

I don't know much about it (or anything for that matter), but couldn't the general component xsd be generated when using the haxeui command line tool to create a new project (I don't how it works so I'm shooting in the dark...), and then the custom user components be generated by a invoked macro (those components will be getting in the final output anyway)...

yeah, not thinking straight again, even if it was possible, it will not reflect the updates in the haxeui libs that we do after creating a new project....

yeah, ill need to think about it... because, even with user components, you might create 100 of them, and only use 2... you wouldnt want the other 98 to be in the output, but you would want completion for all of them "just in case"... its a tough one... i think the "seperate hxml" file is the best approach to investigate first.

yeah, it seems to be the best first approach to the matter, even so, it will be a tricky one

github actions could create xsd of components and commit xsd to haxeui-core. That way maintenance goes away and macros, or other process, just do user components

hello again hashtag haxe ui

i gave up on wxwidgets lmao

i switched the backend over to openfl and it worked immediately

what problem did you have with hxWidgets?

I was already doing a spectrum one but not backend agnostic (I'm using only openfl so I don't need it to be). But I was struggling because there's no way to set a components value in code without triggering its onChange event which made things a little harder for me. But in any case a can make a simpler version myself anyway. And on min-width, it simply doesn't work. 🙂

Btw, Congrats on the wedding @bright-gpu-74537, wish you all the best and the best day ever to you!

well, why do you need to set a component value and not trigger a onChange event? But if that's the case there's ways to deal with that, but without knowing the specifics...

My problem is because I have components cyclically reacting to each other changes which make them react forever due to floating point error

But I already have a strategy to work around that. I just have to get rid of the floating point error in the color calculations so that when I set the exact same value, onChange is not triggered again

floating point error was occurring specially when converting between RGB and HSV

ok, glad to know that you have already a solution/strategy to work around that. Any time you need more help with that, let us know.

@bright-gpu-74537 Is it normal there is no Change event when we modify text on a textArea ?

I had the same problem with onchange not firing on a textarea , but found onfocusout as a workaround

Ian is not likely to reply for a few days at least, he is getting married

I understand. I used AdrianV workaround.

Indeed, the textarea will not fire a change event when we modify the text property directly, like what is happening with textfield, but you could use the @flaky-flag-48397 workaround or you could dispatch a change event right after you modify the text property (

textarea.dispatch(new UIEvent(UIEvent.CHANGE));

), and in this way you don't have to change the logic when a fix is committed, just have to find and remove the "extra" dispatches and the rest remains the same (this is to avoid, when the fix is committed, having different type of events being handled in two different places, or if both are pointed to the same handler, you will have two firings "catched" for the same reason....)

sounds like a bug yeah