Converted TableLayoutWdg to use <div> elements - Printable Version +- TACTIC Open Source (http://forum.southpawtech.com) +-- Forum: TACTIC Open Source (http://forum.southpawtech.com/forumdisplay.php?fid=3) +--- Forum: TACTIC Discussion (http://forum.southpawtech.com/forumdisplay.php?fid=4) +--- Thread: Converted TableLayoutWdg to use <div> elements (/showthread.php?tid=231) |
RE: Converted TableLayoutWdg to use <div> elements - Diego - 07-22-2021 (07-22-2021, 06:49 PM)remkonoteboom Wrote: The difference between something like TACTIC and Google Sheets, etc is that data changes have little to no repercussions. For example, if I misspell a word in a Google doc or change a number in a spreadsheet, the worst that can happen is somebody sees that mistake as I quickly correct it. Yes that's what I was trying to say when I was referring to the triggers problem. Anyway rigging an "auto save" behavior to be called in place of spt.table.set_changed_color shouldn't be to difficult, we could set it with a kwarg auto_save for TableLayoutWdg, defaults to false and can be activated for views where it is wanted RE: Converted TableLayoutWdg to use <div> elements - listy - 07-22-2021 (07-22-2021, 08:34 PM)Diego Wrote: Anyway rigging an "auto save" behavior to be called in place of spt.table.set_changed_color shouldn't be to difficult, we could set it with a kwarg auto_save for TableLayoutWdg, defaults to false and can be activated for views where it is wanted This is not a real problem i think Let's hold our breath and wait till JSX will be done. And then we can do any bells and whistles modern users like RE: Converted TableLayoutWdg to use <div> elements - remkonoteboom - 07-22-2021 Well, saving the table is pretty easy: spt.table.save_changes() If this is called instead of changing the row/cell color, it will save. It does update the row, so some performance would be impacted in its current implementation. RE: Converted TableLayoutWdg to use <div> elements - Diego - 07-26-2021 Going back to the thread topic. I found some problems in column alignment when a column is resized and the the reload icon is clicked, tactic loads the first 4 rows than from the fifth onward they become misaligned. Resizing the column usually snap the cells in line again. However I couldn't reproduce the bug with the vfx plugin, I'm still trying to find why! RE: Converted TableLayoutWdg to use <div> elements - remkonoteboom - 07-26-2021 Ok, I will look into that. These are dynamically loaded rows. The first 4 (by default) are loaded with the header and the others are dynamically loaded in. These rows are, for some reason, deciding at certain points to draw their own size rather than using the header size. RE: Converted TableLayoutWdg to use <div> elements - listy - 07-26-2021 (07-26-2021, 06:43 PM)remkonoteboom Wrote: Ok, I will look into that. These are dynamically loaded rows. The first 4 (by default) are loaded with the header and the others are dynamically loaded in.http://forum.southpawtech.com/showthread.php?tid=231&pid=1317#pid1317 Of you going to look at this, take a look on TaskElementWidget with different pipelines (see the screenshot) RE: Converted TableLayoutWdg to use <div> elements - remkonoteboom - 07-28-2021 I just made another commit which hopefully fixes the misaligned rows on refresh (and sometimes reload). RE: Converted TableLayoutWdg to use <div> elements - Nachogor - 08-02-2021 Still on your branch, right? RE: Converted TableLayoutWdg to use <div> elements - listy - 08-02-2021 (08-02-2021, 12:24 PM)Nachogor Wrote: Still on your branch, right?It has bunch of issues, and not fully tested in production. RE: Converted TableLayoutWdg to use <div> elements - dankitchen - 08-02-2021 I gave this new table structure a test on my internal system and so far it seems to be working well. Likely a good change! |