https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    not sure... cache issue by the sound of it
  • c
    the logic still works and everything, but the formatting just goes
  • c
    yeah
  • b
    might make sense to ask in #459827960006967325
  • f
    http://haxeui.org/builder/?b3d7f4b2 Why doesn't the color picker emit a change event once it's inside a table ? I've tried to put allowInteraction, but it doesnt seem to do anything
  • b
    no idea, seems like a bug
  • b
    will check it out on the morrow šŸ™‚
  • f
    okay šŸ™‚ good night ! šŸ™‚
  • b
    ok, so the issue is that you have to kinda link up columns ids, item renderer components and data fields for table to understand what is what: http://haxeui.org/builder/?d1ece337
  • b
    oh, i might be wrong about that... you could be right, change might not be being attached at all... two secs, confirming
  • b
    OK, so no, its all working correctly... the issue i think with your code is you are adding an instance of colourpicker to the itemRenderer, but that instance isnt the one that ends up in the tableview, since the item renderer (and its children) get `.clone()`d for each item in the table
  • b
    and event handlers will not be cloned (for obvious reasons)...
  • b
    you are better off listening for a "item component event" on the table, which will tell you when and interactive component has changed in the table
  • b
  • f
    Hmm, I'll try the item render event later and I'll tell you. But in fact, the builder example I did was maybe bad ( I had badly simplifify my example it seems ...) , in my own case, I was extending the color picker and had bound the event. So I'm not sure if it's the case. because I did this for all other type fields of castleDB data (text, int, enumaration(list), flags) and all the other ones worked.
  • b
    might need a different repro then, but in my experiments it all look sensible... i dont see how an event on a button (added to the .itemRenderer) can be cloned, but maybe ive forgotten about something
  • b
    also, for what i think you are doing, its probably not ideal anyway to try and do it the way you are doing it... the way i would consider doing it, is create discrete item renderers for each type, and then just "addComponent" on the table... it will work out its a renderer and construct things appropriately
  • f
    Saying this, I have only extensively tested on html5 for now, so everything worked but it's just maybe on html5 . I think it din't work perfectly on openfl, and it must be because of that
  • f
    So I think I'll try your method šŸ™‚ BTW, I am now implement a Textfield event: when you press "enter" , it generates an Enter event. Could I make a PR when it's finished ? I have it working on openfl, html, and right now adapting it in hxWidgets, but I don't know really know the other backends
  • b
    by all means, send a PR, this is something i need to do, but i also want to figure out a way to do it for other components, for example, dialogs, forms, etc... i think they need like a "default action" or something but the terminology is bad since actions is something else in haxeui
  • f
    Ok great, once hxwidgets is done I'll send the PRs šŸ™‚ And if ever I found a good name for default action , I'll tell you ( but I'm bad at naming things )
  • b
    > but I'm bad at naming things same, its par for the course...
  • b
    > There are only three hard problems in computer science: Cache invalidation, naming things, and off-by-one errors. šŸ˜„
  • b
    ... i was thinking about a new UIEvent... UIEvent.SUBMIT... this could also be cancellable, and would bubble up... but i probably need to think about it a little first
  • f
    Haha . And the difficult thing with a public library is that you just can't rename things. When I debug my own code, I usually take advantage to rename the functions ( what's this thing !? why is it name like this ? )
  • f
    I think the name SUBMIT is nice
  • b
    locking myself into a badly named api, is always my concern šŸ™‚
  • b
    maybe "USER_SUBMIT" (?), incase there is a need for SUBMIT at some point? Since, i think at least, this event will only ever be dispatched as the result of a user interaction
  • f
    We can see your experience ! Good forward thinking šŸ˜‰ I like it less, but indeed it must be better.
  • b
    ... ... i also like it less
1...138113821383...1687Latest