Open JamesDunne opened 8 months ago
Yeah, that's expected right now. The reason is that the table cells are ephemeral -- they are only around while visible on the screen and even then, only when directly interacted with, usually only for drawing purposes. I believe I do install the cell and forward most mouse events to them, then uninstall it... but I'm pretty sure I don't do that for keyboard input (mainly because my own uses didn't need it).
I don't think this would hard to add. If you provided a list of specific things that are broken, that would be helpful.
Gotcha. Pretty much nothing works as far as interactivity of the field when it's in the cell. Can't select, can't edit, can't type, etc. The mouse cursor changes to an editing cursor when hovered over but that's the extent of it.
OK, good to know. Some things are forwarded, but clearly not enough. To date, the only thing I've used that for is a custom label that changes its contents when clicked on. Anyway, not sure when I'll get around to adding more support for this, but will keep it in mind next time I have some spare time and am looking for something to work on.
No worries, I can find a workaround for my use case. Aside: loving this library so far. Great work!
When returning a
*Field
widget fromColumnCell()
to act as an editable text field, it seems all interactive functionality of the*Field
does not work within the table. I've made sure to use a single*Field
instance returned fromColumnCell()
. I can submit a tiny demo code snippet if need be. Thanks!