¿de que componente derivar? más discusión que otra cosa, aclaro :)

[pvizcay]

hola amigos del foro,

estoy haciendo una versión dbaware del componente TCheckListBox, el probema es que este no viene con su versión TCustomCheckListBox, por lo tanto si derivo de el, quedará expuesta todos los metodos y propiedades published del mismo...

si derivo de la clase anterior, TCusmtomListBox, tengo que codificar toda la parte de los checkboxes asi que tampoco me interesa..

decidí entonces crear un control que declare como privado un TCheckListBox y exponga las propiedades y métodos correctos y lo maneje como componente interno, sin acceso desde afuera..

según uds. ¿cúal sería el control idóneo desde el cúal tengo que derivar para lograr esto? si derivo de TWinControl, terminaría con dos wndhandles, el del TWinControl y el TCheckListBox interior, una duplicación de recursos desde mi punto de vista..

saludos!

[dec]

Hola,

Planteas una cuestión curiosa, y yo, definitivamente, me veo superado, pero, viendo la clase "TCheckListBox"... implementada en una sola unidad... a falta de mejores respuestas creo que yo partiría de ahí mismo.

Quiero decir que no derivaría el componente de "TCheckListBox", sino que aprovecharía el código fuente de dicha clase, modificándolo como mejor convenga.

¿Se entiende lo que quiero decir? Sí; efectivamente, es muy bruto. Hablo de copiar la unidad "CheckLst" donde se implementa el componente "TCheckListBox" y a partir de ahí realizar las modificaciones oportunas.

PD. Aclaro que no abogo por utilizar siempre una solución como esta. Se me ha ocurrido al echar un vistazo a este caso en concreto.

[roman]

Y, ¿qué propiedades tiene TCheckListBox que quisiéramos no ver publicadas?

// Saludos

[pvizcay]

con respecto a lo de copiar código, bueno se han escribido libros enteros sobre porque no es buena idea.. posibilidad de introducir bugs, que no se actualize el control en caso de una mejora, son dos de las cosas que se me vienen a la mente..

osea es una cuestión más de "que sería lo correcto" esto.. para eso me parece mucho mejor codificar los eventos del control para realizar lo mismo y copiar el código de los eventos.. por lo menos se copia menos código..

con respecto a la otra cuestión, el TCheckListBox tiene como published todas las propiedades para trabajar la lista, agregar elementos, eliminar, etc. osea me podrían sacar un elemento que existe en la base de datos o viceversa, yo tengo que definir cuando eso sucede, el usuario no debe manejar la lista interna.. es por eso que los controles de delphi vienen con su versión "Custom" para poder mejorarlos sin exponer métodos y propiedades que permiten una "doble interfaz" al control..

saludos

[dec]

Hola,

No digo que copiar el código no sea una mala idea como norma general, pero, en este caso... puede ser una solución. Piensa que en este caso no cuentas con un componente "TCustom..." y yo estaba pensando en que podrías tú mismo crearlo, partiendo del código fuente de la unidad "CheckLst".

Sería como crear un componente de cero. ¿Que de esa forma no obtienes posibles mejoras que se dieran en un componente del que heredaras? Cierto, pero, también es cierto que hay componentes que se escriben desde cero... y no pasa nada. Uno se hace cargo de ellos y eso es lo que hay. ¿Que puede uno introducir Bugs? Claro... y también quitarlos, si los hubiera...

No sé. Creo que el componente de que hablamos "TCheckListBox" no cuenta con un "TCustom..." por algún motivo... acaso porque se añadiera a la VCL de una forma incompleta... yo no lo sé. Por eso digo que en este caso concreto tal vez merezca la pena copiar el código, basarnos en el mismo y crear nuestro propio "TCustom..." o, directamente, el componente que necesitamos.

[pvizcay]

hola dec

ah si, sin duda es una solución..

pero no creo que sea lo mejor desde el concepto de la ingeniería de software ni desde ninguna otra perspectiva.. por eso dije que este era un post de discusión

salu2 y grax por contestar!

[dec]

Hola,


(...) no creo que sea lo mejor desde el concepto de la ingeniería de software ni desde ninguna otra perspectiva..


Eso es estupendo. Porque entonces alguien debe conocer alguna solución que cumpla con los requerimientos y quiero conocerla. :)

Pero de todos modos el asunto no me queda muy claro. ¿En qué no se cumplen los requisitos si yo, sencillamente, me baso en el código fuente del componente "TCheckListBox" para conseguir un componente que se adapte a mis necesidades? Algo me estoy perdiendo y no sé qué es...

[roman]

Hola,

Yo estoy de acuerdo con David. Te basas en un código ya existente para comenzar algo nuevo. A partir de ahí, el desarrollo es tuyo y cumplirá con todas las perspectivas que quieras de la ingeniería. Es decir, te vas olvidar en lo sucesivo del código original, y lo vas a hacer porque, según los parámetros que te impones, ese mismo componente original no satisface tales perspectivas.

Tal solución no sólo es buena, sino bastante más práctica que la de crear un wraper del control original, al menos si quieres seguir teniendo una representación visual en tiempo de diseño del control.

Ahora, si deseas permanecer con esa idea- la del wraper,la componente más adecuada para descender es sin duda TComponent. Tendrás un objeto mediante el cual podrás llenar propiedades en el inspector de objetos y que se mostrará durante la ejecución.

// Saludos