# haxe-ui
- f
fast-rain-20339
07/02/2020, 7:40 AMNo worries 🙂 Strange it worked for you 🤔 - b
bright-gpu-74537
07/02/2020, 7:40 AMno haxeui-kha, haxeui-html5 - b
bright-gpu-74537
07/02/2020, 7:40 AMi didnt test kha so half wrote it blind with the (obviously erroneous) assumption it would just work - f
fast-rain-20339
07/02/2020, 7:41 AMYup no worries. This is just for little asset previews, so I should be able to move on without a problem 🙂 - b
bright-gpu-74537
07/02/2020, 7:42 AMcool - its a very useful change anyway, i mean, i could create a canvas now, draw what ever i want to it, set that as a data url for an html img and then use that in haxeui Image::resource... which is pretty swish - b
bright-gpu-74537
07/02/2020, 7:42 AMsame should have happened for kha - f
fast-rain-20339
07/02/2020, 7:43 AMAhh yeah that is pretty cool, and probably something that I may end up having in my app. I've been considering asset creation within the editor as a long term feature 😄 - b
bright-gpu-74537
07/02/2020, 7:49 AMhaxeui.org is back up - f
fast-rain-20339
07/02/2020, 7:50 AMAwesome 👍 Gonna look into making these listview elements selectable 😄 - b
bright-gpu-74537
07/02/2020, 7:50 AMand back to 25 second build times 😄 - b
bright-gpu-74537
07/02/2020, 7:50 AM> Gonna look into making these listview elements selectable - b
bright-gpu-74537
07/02/2020, 7:50 AM? - f
fast-rain-20339
07/02/2020, 7:51 AMShould be pretty simple, just going to try and make @:bind tell me which listview element was clicked 🙂 - b
bright-gpu-74537
07/02/2020, 7:51 AMoh, you mean in your app, thought you meant that they were able to be selected - b
bright-gpu-74537
07/02/2020, 7:51 AMyeah,
above a function should be it@:bind(myList, UIEvent.CHANGE) - f
fast-rain-20339
07/02/2020, 7:52 AMAh okay, cool. Seems like most events are
, I should have just tried it lolUIEvent.CHANGE - b
bright-gpu-74537
07/02/2020, 7:52 AM(assuming you are using the @:build macro) - f
fast-rain-20339
07/02/2020, 7:52 AMYep - b
bright-gpu-74537
07/02/2020, 7:52 AMcool... 🙂 - b
bright-gpu-74537
07/02/2020, 7:53 AMyeah, generally components are "changeable", apart from the fact it makes sense and is consistent it also makes things easier with item renderers - b
bright-gpu-74537
07/02/2020, 7:54 AMbut really, thats a bonus, in reality its because "change" is semantically appropriate - f
fast-rain-20339
07/02/2020, 7:55 AMYep, nice. On first impression, the idea of most things using the one event feels wrong, but it does make a lot of sense, because the data can just be gotten from the component directly, rather than the event 👍 - b
bright-gpu-74537
07/02/2020, 7:56 AMyeah, so out of interest, you would have thought SliderChangeEvent, ProgressChangeEvent, CheckBoxChangeEvent, TabViewPageChangeEvent would have made more sense? - f
fast-rain-20339
07/02/2020, 7:57 AMInitially, yes, with each of those events perhaps passing event related info (whether the checkbox is ticked, etc). Really though, it's just more overhead - b
bright-gpu-74537
07/02/2020, 7:59 AMhmmmm, i guess, i personally prefer a generic "onchange"... keeps things nice and simple... you can kind half know that if the component can change then "UIEvent.CHANGE" is probably what you want - f
fast-rain-20339
07/02/2020, 7:59 AMYep that simplicity is good. I think multiple event types is more appropriate when the range of possible events is much larger - b
bright-gpu-74537
07/02/2020, 8:00 AMthere are exceptions, mainly where it doesnt make semantic sense and also where you likely DO want extra info in the event, MenuEvent.MENU_SELECTED (.selectedMenu, selectedMenuItem), MouseEvent.CLICK (.screenX, .localY) - f
fast-rain-20339
07/02/2020, 8:00 AMCool 👍 - b
bright-gpu-74537
07/02/2020, 8:01 AMothers too, that i can think of off hand, but in general, i like the simplicity of change, and as i mentioned, it also makes wiring up components events in custom item renderers pretty simple - b
bright-gpu-74537
07/02/2020, 8:01 AMie, its either gonna be CHANGE, or CLICK