La segunda opción es ingeniosa, no cabe duda, pero cargaríamos con un componente de palo que sería como un invitado molesto
. La tercera opción es la más sencilla pero, como dice
maese Casimiro, un poco chapucera y quizá buena para algo temporal.
Por RTTI, pensaba yo más bien en leer un DFM como lo hace el IDE, usando un TReader, pero creo que puede complicarse el asunto al no saber de antemano las clases que deben registrarse.
La primera opción, el
parseo del texto, creo que sería la más adecuada, pero de pronto no me parece tan sencilla o al alcance de cualquiera, considerando que el DBGrid puede estar anidado en otros contenedores y hay que determinar bien dónde termina la lista de sus propiedades. Vamos, creo que es algo que parece sencillo pero que presentará complicaciones a la hora de implementarlo.
Creo que es un reto interesante, y me parece que sería igual de sencillo (e igual de difícil) pensar en algo más general:
parsear todo el DFM y almacenarlo en una estructura de datos manejable por código. Pero desconozco con qué detalles podemos encontrarnos. Por ejemplo, en principio había pensado que el DFM era una lista de propiedades y subobjetos
Código:
object name: class
property = value
property = value
...
object name: class
..
end
..
pero ahora me recuerda
maese Neftali que hay elementos como las columnas, que son colecciones:
Código:
property = <
item
property = value
property = value
...
end
item
property = value
property = value
...
end
...
¿Con qué otras sopresas podemos encontrarnos?
LineComment Saludos