I have a few dropdown editors in a power table. I return editable for all columns using the isCellEditable extension function. Unless I mark the cell as editable in the Column Attributes dataset, the Cell Renderer extension function is not called and the dropdown does not appear.
I am using 7.9.4.
Is this quark fixed in an available new version?
Has anyone else had this problem?
Has there been any movement with this? Does anyone else have this problem or better yet a workaround? Simply editing the column attributes does not work, because I am reusing the same table component for 4 different datasets.
The workaround is to populate the column attributes dataset with all possible columns from your four datasets. You cannot use the customizer for this, as it always prunes to the columns present at the time it is run, but you can copy each set to the clipboard, assemble the dataset CSV in a text editor, and paste it back. To make it more robust, use a custom dataset property to hold your desired startup attributes and bind your c-a-ds to it.
Thank you. That will work.
Is this problem solved in a future version? I am running 7.9.4.
I don’t think it’s technically a bug. It’s always worked this way – the table components weren’t really designed to handle many different datasets. Consider putting it up on the feature wish list.
I would not call this a bug.
I would call the column attributes dataset not updating a bug. After switching this does not and I think it should. Having to manually keep this up to date is unintuitive. I understand if the settings cannot be cached when we switch between datasets, because that is probably just confusing and inefficient from your end.
No, the c-a-ds has never updated except by using the customizer in the designer. It is exposed as a property specifically to allow scripted access for functionality beyond what the customizer can do. And even if one agreed that it should update, how exactly would it do that? Where would the missing information come from? Thin air?
If you wish truly automatic operation, use a property change on 'data' to compute a new c-a-ds yourself. Then you have full freedom to supply the missing data as you see fit.
If I cannot programmatically go through rows of c-a-ds and update the editable attribute without first adding the rows every time I switch tables, then I do not think calls to the renderer extension function should be limited to columns marked editable in the c-a-ds. It looks like this was done for a small efficiency boost, but it would be better if it were based on a relationship with the editable extension function. You could check whether the editable extension function said the column was editable and then if it is, call the renderer extension function.
Of course you can’t set the editable attribute without adding a row for the column name in question. How could it possibly be otherwise? You’ve probably now realized that the problem with the missing rows is that “editable” is but one of many properties needed to construct a new entry. You need a value for each attribute. There is no way to satisfy your desires. The whole point of the c-a-ds is to supply attributes that can be different from default rendering. Your complaint boils down to you not liking the default for the editable attribute for missing rows in c-a-ds. But if you change that default, you break all existing IA projects that don’t need the c-a-ds for every column.
You have total control over the c-a-ds in your own projects, whether by preloading as I first suggested or by scripting. You need to use one of these two techniques. Any automatic update of c-a-ds in a new version of these components would break backward compatibility.