FiveTech Software tech support forums

Hola,

¿Existe en FW alguna clase que sea equivalente a TDataBase pero que maneje arrays ?

La idea es gestionar un array como si fuera una dbf, skip(), recno(), seek(), etc.

Si no existe, se podría crear heredada de una TTable y a partir de ésta, crear TDbfTable (Actual TDatabase), TArrayTable, TMysqTable, etc.

Si alguien conoce algo o está interesado, podríamos crearlas si no existen.

Podríamos pasarle a un wbrowse un oTable y que funcione, independiente del tipo que sea, una dbf o un array o cualquier otra.

Creo que algo de esto que quieres lo hace el xBrowse/TDolphin, lo uso con array, dbf, ado, query...saludos...

Joaquín,

Para mi debería haber una clase TDataSet (conjunto de datos) de donde derivaría por un lado TArray y por otra parte TDataBase.

Los Métodos de TDataSet en su mayoría serían virtuales (VIRTUAL)

En teoría podrías usar TDatabase directamente si lo que tienes como dataset es un rdd.
Por suerte en harbour existe ARRAY RDD. Mira en harbour\src\rdd\usrrdd\rdds es un RDD basado en usrRDD.

Yo personalmente me crearía una clase de manejo de array con los métodos que mencionas

Antonio,

Esa era exáctamente la idea, crear la mayoría de los métodos virtuales.

Tengo una duda, Harbour al definirle un método VIRTUAL, si lo usas en la clase hija, ¿ "Chilla" ?, porque en Java sí estaba acostumbrado a definirlos y me obligaba
a crearlos y me avisaba de los no creados.

Si eso no funciona en HB, tengo una opción que es:
METHOD seek(x) INLINE msginfo("Seek no definido en la clase hija")

Pues si alguien se apunta, podríamos empezar con TDataset, con lo mínimo necesario casi todo VIRTUAL, adaptar una TdbfDataset y TArrayDataset.

Lo que sí haría desde el principio es una apartado PROTECTED: y uno VISIBLE:

Manu,

Creo que sí, mejor una jerarquía de clases bien diseñadas y separadas del GUI, que usar rdd´s.

Joaquin,

Si declaras métodos virtuales en la clase padre, no tienes por que volver a crearlos en las clases derivadas.

Solo si necesitases implementar un determinado comportamiento y que deje de ser virtual

Claro Antonio,

A eso me refiero, si el método seek() debe existir en todas las hijas, como lo obligo?

Imagina, creo seek en el TDataset VIRTUAL, y lo uso en un browse.

Ahora, creo un TArrayDataset y no defino seek, ¿Qué ocurre si uso el browse con TArrayDataset cuando use el método seek ?

En mi caso, avisa con un msginfo en tiempo de desarrollo, indicándote que seek() debe ser definida forzosamente en todas las hijas.

Mi pregunta es si HB avisa de los métodos virtuales que no se han definido en los hijos.

Joaquín,

Si tu declaras el método Seek() en la clase padre, automaticamente todas sus clases derivadas lo tienen.

Si en alguna clase derivada lo quieres cambiar, pues lo vuelves a definir ("lo redefines")

Te refieres a esto ?

Antonio, No es eso,

Si declaro METHOD seek(x) VIRTUAL , es decir, no tiene implementaciòn en el padre.

Cuando creo una CLASS Hija FROM Padre, quiero que sea obligatorio implementar el código del mètodo seek en la clase
Hija, por eso, Harbour me debería avisar con un warning, indicado que no està implementado en ningùn lugar.

Lo cual implica, que si es VISIBLE: cualquier programador puede querer usar el mètodo seek, pero como no existe, daría error de ejecuciòn.

Joaquín,

No es asi exactamente. Los métodos virtuales en Harbour no hacen nada. Existen pero es como si no tuviesen código.

Si los llamas no dan error y por eso no es obligatorio redefinirlos, salvo que quieras realmente implementar un determinado comprtamiento.

Ok!

Es decir, en harbour no sirven casi para nada, es sòlo un recordatorio,

En otros lenguajes como java, si tiene esa utilidad.

Gracias,

Joaquín,

Asi es. Es solo para que ayudarte a trazar el plan, el diseño que quieres darle a tu clase, a tus ideas

Joaquín implementar eso que hace java en harbour es muy fácil.

En los métodos VIRTUAL cambia virtual por un INLINE que lance un error de la clase TERROR.
Puedes implementar un metodo THROW que lance esa exepccion.
Desgraciadamente eso se genera en tiempo de ejecución y no de compilación como en Java. Lo que tiene Harbour en este sentido es muy simplón

No sabría decir si Harbour posee esas capacidades para el VIRTUAL.
Lo que sí sé es que Harbour, su implementacion, sus características, van muchas veces más avanzadas que los conocimientos que tenemos de él.
Y si hablamos del vikthor's fork, traducido a release, Harbour 3.4 ya ni te cuento. Hay que ser un buen "seguidor" de la evolución de Harbour para saber si esto o aquello está o no.

Habría que buscar en las ayudas de Harbour más actualizadas y / o el changelog para saber si eso y mil características más existen o no.

A mi me pasa.