[…continuing from another forum section…]
Would your grid allow to be filled by just any xml or json file?, if it so, it must be an exceptional implementation because it doesn't sound right comparing a fixed file format like a csv versus something completely arbitrary like json or xml.
Obviously you need to be able to specify what must be displayed in the StringGrid - I've done just that in another application, but still that functionality does not and should not belong in the TStringGrid widget.
The same can be said for CSV files. Yes, CSV is a much simpler structure than JSON or XML, but there is also cases where I don't want to display all columns (not supported by the current implementation in LCL), or maybe even apply a filter while loading (not supported by the current implementation in LCL). What is there is the most basic of features and thus not very useful in many cases.
And like I said before, it was probably added to the TStringGrid API in haste, so now you are stuck with that, and only with limited CSV functionality and no support for other popular formats (TAB, JSON, XML etc).
I still think it would be best to deprecate those two methods, and move the functionality (as-is) out to a class that is more flexible. Another benefit would be that others will then be able to extend that functionality by creating their own descendants in their own applications. No need to keep modifying LCL.
This was not meant a personal dig at you (appologies if I came across like that). You contribute so much to LCL which is fantastic. All I'm saying is that good design is hard (I often struggle with that too), and sometimes it is worth changing a design to make it better.
Recent
