Xailer & OZ Software

Saludos:
Tengo una aplicación que necesita el mantenimiento de varías bases de
datos, he visto que en ejemplos, y dentro de ese directorio en la carpeta
DataContols viene un mantenimiento que se llama DBFData2, en el ejemplo
viene un formulario que se ajusta exactamente a como poder hacer los
mantenimientos pero claro hacer siempre el mismo formulario cambiando las
columnas en la DBBrowser y cambiando la DataSource para que apunte a otra
Base de datos supone una cantidad de código innecesario, he pensado que
podía utilizar el formulario de la DBFData2 para esto pero utilizando
después dependiendo de la base de datos a mantener un formulario por cada
base de datos que configure las columnas de la DBBrowser según los campos
requeridos y que en el menú las llamadas a los métodos que sean comunes que
no se contengan en el formulario común sean implementados en cada formulario
de la base de datos que corresponda.
No se si me he explicado bien si no es así ruego me perdonéis.
Por lo tanto tendría un solo formulario llamémoslo FormComun
Y tantos PRG como Bases a mantener PRG1,PRG2,PRG3 etc.,.
Estas son mis preguntas:
1º) Como llamaría desde cada PRG a el FormComun.
2º) Como Configuraría desde los PRGs la opción ::SetTag( Value ) del
FormComun.
3º) Como Configuraría desde los PRGs la DataSet, del FormComun.
4º) Como añadiría columnas a la DBBrowser, del FormComun según los
campos de Base de datos que este utilizando.
En fin seguiría preguntando pero a lo mejor estoy diciendo algo que se
resuelve de otra forma más fácilmente.
Es posible hacer que los PRG hereden de FormComun para usar sus
controles.
En fin el que tenga la deferencia de molestarse en contestarme le estaré
agradecido ya que he implementado ya siete formularios de siete bases
auxiliares y la verdad me parece que debe de haber una forma mas fácil de
hacerlo.
José Ramón Castro Polinio
JRCPOLI@terra.es

yo hice eso exactamente, y en unos minutos armo el mantenimiento de un
catalogo de datos.
El asunto es que tengo problemas al querer usarlo en MDI, y en lo cual me
esta hechando la mano F.Gimenez.
En uno de los mensajes anteriores por ahi postee el ejemplo.
Saludos.
ramon zea

José,
hay varias formas de hacerlo; esta es una de ellas:
1) Crea un formulario con el browse y todo lo que necesites, pero sin
definir las columnas. También puedes añadir los métodos comunes que van a
tener todos los mantenimientos, incluso declarándolos como VIRTUAL para
desarrollarlos después.
2) Haz doble click en el evento OnInitialize de ese formulario, para que te
cree el método FormInitialize.
3) El .prg quedaría más o menos así:
CLASS TFormBase FROM TForm
COMPONENT ...
...
METHOD FormInitialize( oSender )
METHOD Load() VIRTUAL
METHOD Save() VIRTUAL
METHOD Report() VIRTUAL
...
ENDCLASS
METHOD FormInitialize( oSender ) CLASS TFormBase
RETURN Nil
4) Ahora crea un .prg (no un formulario), que quede más o menos así:
CLASS TClientes FROM TFormBase
METHOD FormInitialize( oSender )
METHOD Load()
METHOD Save()
METHOD Report()
ENDCLASS
METHOD FormInitialize( oSender ) CLASS TClientes
// Aqui tienes que rellenar las columnas del browse
// y cualquier inicializacion que necesites
RETURN Super:FormInitialize( oSender )
METHOD Load() CLASS TClientes
// Pon aqui lo que haga falta
RETURN Nil
METHOD Save() CLASS TClientes
// Pon aqui lo que haga falta
RETURN Nil
METHOD Report() CLASS TClientes
// Pon aqui lo que haga falta
RETURN Nil
5) Repite el paso 4) por cada mantenimiento que necesites, escribiendo el
código que corresponda en cada método.
6) Para llamar a los mantenimientos, lo puedes hacer así:
TClientes():New( Application:oMainForm ):Show()
Esta es la idea. Sólo tienes que desarrollarla de acuerdo a tus necesidades.
--
Un saludo,
José F. Giménez

Gracias por la respuesta.
Ya de paso te digo que el formulario que hay como ejemplo ´que se llama
DBFData2 tiene un pequeño error al definir el menú y queda oculto por la
ToolBar de forma que algunas veces los botones de la Toolbar se destruyen
apareciendo cuando se pasa el ratón por encima es una cosa sin importancia
ya que solo se trata de definir ina variable LOCAL para el menú.
De la respuesta que me has dado hay de momento sin empezar a
desarrollarla una cosa que no he cogido que quieres decir con declararlos
Virtual, eso no lo he entendido, el resto según lo implemente me surgiran
las preguntas que si no os importa pasaré.
Saludos.
José Ramón Castro
JRCPOLI@terra.es
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=42e0bb70@ozsrvnegro.ozlan.local...]42e0bb70@ozsrvnegro.ozlan.local...[/email]
> José,
>
> hay varias formas de hacerlo; esta es una de ellas:
>
> 1) Crea un formulario con el browse y todo lo que necesites, pero sin
> definir las columnas. También puedes añadir los métodos comunes que van a
> tener todos los mantenimientos, incluso declarándolos como VIRTUAL para
> desarrollarlos después.
>
> 2) Haz doble click en el evento OnInitialize de ese formulario, para que
> te
> cree el método FormInitialize.
>
> 3) El .prg quedaría más o menos así:
>
> CLASS TFormBase FROM TForm
> COMPONENT ...
> ...
> METHOD FormInitialize( oSender )
> METHOD Load() VIRTUAL
> METHOD Save() VIRTUAL
> METHOD Report() VIRTUAL
> ...
> ENDCLASS
>
> METHOD FormInitialize( oSender ) CLASS TFormBase
> RETURN Nil
>
> 4) Ahora crea un .prg (no un formulario), que quede más o menos así:
>
> CLASS TClientes FROM TFormBase
>
> METHOD FormInitialize( oSender )
> METHOD Load()
> METHOD Save()
> METHOD Report()
>
> ENDCLASS
>
> METHOD FormInitialize( oSender ) CLASS TClientes
> // Aqui tienes que rellenar las columnas del browse
> // y cualquier inicializacion que necesites
> RETURN Super:FormInitialize( oSender )
>
> METHOD Load() CLASS TClientes
> // Pon aqui lo que haga falta
> RETURN Nil
>
> METHOD Save() CLASS TClientes
> // Pon aqui lo que haga falta
> RETURN Nil
>
> METHOD Report() CLASS TClientes
> // Pon aqui lo que haga falta
> RETURN Nil
>
>
> 5) Repite el paso 4) por cada mantenimiento que necesites, escribiendo el
> código que corresponda en cada método.
>
> 6) Para llamar a los mantenimientos, lo puedes hacer así:
>
> TClientes():New( Application:oMainForm ):Show()
>
>
> Esta es la idea. Sólo tienes que desarrollarla de acuerdo a tus
> necesidades.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

José Ramón,
> Ya de paso te digo que el formulario que hay como ejemplo ´que se llama
> DBFData2 tiene un pequeño error al definir el menú y queda oculto por la
> ToolBar de forma que algunas veces los botones de la Toolbar se destruyen
> apareciendo cuando se pasa el ratón por encima es una cosa sin importancia
> ya que solo se trata de definir ina variable LOCAL para el menú.
No consigo reproducir el problema que comentas. Por favor, indícame
exactamente los pasos a seguir para reproducirlo.
> De la respuesta que me has dado hay de momento sin empezar a
> desarrollarla una cosa que no he cogido que quieres decir con declararlos
> Virtual, eso no lo he entendido, el resto según lo implemente me surgiran
> las preguntas que si no os importa pasaré.
Los métodos virtuales son métodos que no hacen absolutamente nada, pero que
existen y si son llamados no se produce ningún error.
Supón que en los mantenimientos utilizas un método al que llamas Listado() y
que es llamado desde p.ej. un botón de una toolbar que hay en la clase base.
Lo normal es que ese método lo desarrolles en cada uno de los
mantenimientos, pero resulta que hay uno que no tiene listado. En ese caso,
deberías también declarar el método en ese mantenimiento, o mejor aún,
declararlo en la clase base, pero sin hacer nada. Si la clase derivada (el
mantenimiento) sobrecarga el método, pues hará lo que tenga que hacer, pero
si no lo sobrecarga pues no hará nada. Vamos, que tendrías que declararlo
así:
CLASS TFormBase FROM TForm
...
METHOD Listado()
...
ENDCLASS
METHOD Listado() CLASS TFormBase
RETURN Nil
Bien, pues esto es exactamente igual (desde el punto de vista funcional)
que:
CLASS TFormBase FROM TForm
...
METHOD Listado() VIRTUAL
...
ENDCLASS
Sé que en otros lenguajes los métodos virtuales tienen otro significado,
pero en xHarbour el que tienen es el que te acabo de explicar.
--
Un saludo,
José F. Giménez

Vale aqui va como esta definido actualmente el ejemplo en el Method.
METHOD FormInitialize( oSender ) CLASS TForm1
LOCAL oSortMenu
LOCAL aTags
LOCAL nFor
set date italian
MENU ::oMenu
MENUITEM "&File"
MENU
MENUITEM "&Append"
MENUITEM "&Edit"
MENUITEM "&Delete"
SEPARATOR
MENUITEM "&Printer configuration" ACTION Printer:Setup( Self )
SEPARATOR
MENUITEM "&Exit" ACTION ::Close()
ENDMENU
MENUITEM "&Help"
MENU
MENUITEM "About..." ;
ACTION ShellAbout( Application:Handle, Application:cTitle,
;
"Copyright Xailer 2003-2004" )
ENDMENU
ENDMENU
Pues bien de esta forma el menú no se ve queda oculto por la ToolBar, y si
pulsas el botón de añadir aparece debajo, borrando parte de los botones de
la Toolbar, por lo menos en la que yo tengo y es la release 4, lo suyo sería
que el menú estubiera visible siempre por eso yo hice esto.
METHOD FormInitialize( oSender ) CLASS TFormFed
LOCAL oSortMenu
LOCAL oMenu
LOCAL aTags
LOCAL nFor
SET DATE italian
MENU oMenu
MENUITEM "&File"
MENU
MENUITEM "&Añadir" ACTION ::AddNew()
MENUITEM "&Editar" ACTION ::Edit()
MENUITEM "&Borrar" ACTION ::Delete()
SEPARATOR
MENUITEM "&Imprimir" ACTION ::Report()
MENUITEM "&Printer configuration" ACTION Printer:Setup( Self )
SEPARATOR
MENUITEM "&Exit" ACTION ::Close()
ENDMENU
MENUITEM "&Mover"
MENU
MENUITEM "Ir al &Primer Registro" ACTION ::oDBw:GoTop()
MENUITEM "Ir al &Siguiente Registro" ACTION ::oDBw:GoDown()
MENUITEM "Ir al &Anterior Registro" ACTION ::oDBw:GoUp()
MENUITEM "Ir al &Ultimo Registro" ACTION ::oDBw:GoBottom()
ENDMENU
MENUITEM "&Help"
MENU
MENUITEM "&Acerca de..." ;
ACTION ShellAbout( Application:Handle, Application:cTitle,
;
"Copyright Xailer 2003-2004" )
ENDMENU
ENDMENU
::oMenu := oMenu
Vuelvo a repetir en Samples DataControls DBFData2.
Añadí algunas cosas al menú de mi consecha, no creo que sean importantes.
Otra cosa que puede ocurrir es que cuando se instale la release 4 sin borrar
la anterior versión no modifique los samples que ya tengas y que lo suyo sea
hacer una instalación nueva cuidando de mover los directorios en la que
tengas aplicaciones o instalarla en otro directorio cosa que yo no he hecho.
Con respecto a la clausula VIRTUAL queda claro se definen por defecto y
luego si se utilizan en el formulario que llama a la subclase entonces hará
lo que hayas puesto en ella y sino no producirá error puesto que el metodo
existe en la clase principal pero no tiene código con la cual no hará nada
mas que un retorno.
Saludos.
José Ramón Castro
JRCPOLI@terra.es
Desde Cartagena (Murcia)
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=42e13da4@ozsrvnegro.ozlan.local...]42e13da4@ozsrvnegro.ozlan.local...[/email]
> José Ramón,
>
>> Ya de paso te digo que el formulario que hay como ejemplo ´que se
>> llama
>> DBFData2 tiene un pequeño error al definir el menú y queda oculto por la
>> ToolBar de forma que algunas veces los botones de la Toolbar se destruyen
>> apareciendo cuando se pasa el ratón por encima es una cosa sin
>> importancia
>> ya que solo se trata de definir ina variable LOCAL para el menú.
>
> No consigo reproducir el problema que comentas. Por favor, indícame
> exactamente los pasos a seguir para reproducirlo.
>
>
>> De la respuesta que me has dado hay de momento sin empezar a
>> desarrollarla una cosa que no he cogido que quieres decir con declararlos
>> Virtual, eso no lo he entendido, el resto según lo implemente me surgiran
>> las preguntas que si no os importa pasaré.
>
> Los métodos virtuales son métodos que no hacen absolutamente nada, pero
> que
> existen y si son llamados no se produce ningún error.
>
> Supón que en los mantenimientos utilizas un método al que llamas Listado()
> y
> que es llamado desde p.ej. un botón de una toolbar que hay en la clase
> base.
> Lo normal es que ese método lo desarrolles en cada uno de los
> mantenimientos, pero resulta que hay uno que no tiene listado. En ese
> caso,
> deberías también declarar el método en ese mantenimiento, o mejor aún,
> declararlo en la clase base, pero sin hacer nada. Si la clase derivada (el
> mantenimiento) sobrecarga el método, pues hará lo que tenga que hacer,
> pero
> si no lo sobrecarga pues no hará nada. Vamos, que tendrías que declararlo
> así:
>
> CLASS TFormBase FROM TForm
> ...
> METHOD Listado()
> ...
> ENDCLASS
>
> METHOD Listado() CLASS TFormBase
> RETURN Nil
>
> Bien, pues esto es exactamente igual (desde el punto de vista funcional)
> que:
>
> CLASS TFormBase FROM TForm
> ...
> METHOD Listado() VIRTUAL
> ...
> ENDCLASS
>
> Sé que en otros lenguajes los métodos virtuales tienen otro significado,
> pero en xHarbour el que tienen es el que te acabo de explicar.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

Ramón,
> Con la opcion VIRTUAL, puedo hacer los metodos y luego reescribirlos en otra
> clase?
Sí­, por supuesto. Incluso puedes poner código en el método de la clase
padre y llamarlo desde la hija.
Tu mismo código con algunas modificaciones:
Method Load() Class TClientes
<TuCodigo>
/* Ejecutar el código de TFormBase:Load()
*/
Super:Load()
<MasCodigo>
Return Nil
Saludos,
José Lalí­n

Saludos:
Lo que ha explicado es que se define por defecto en la clase principal sin
poner código dentro solo un retorno, y la defines completamente en el
formulario que llame o utilice el principal, pero no pones código en los dos
sitios, sino en uno solo, lo que pasa es que puedes hacer que una Toolbar
contenga algunos botones que en unos mantenimientos utilices y en otros no,
sino estubiera definida en algún sitio daría un error y de esta forma no da
error porque encuentra el metodo pero solo produce un retorno.
José Ramón Castro
JRCPOLI@terra.es
"Ramón Zea" <zeasoftware@hotmail.com> escribió en el mensaje
news:42e15592$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Con la opcion VIRTUAL, puedo hacer los metodos y luego reescribirlos en
> otra
> clase?
> algo asi:
>
> CLASS TFormBase FROM TForm
> COMPONENT ...
> ...
> METHOD FormInitialize( oSender )
> METHOD Load() VIRTUAL
> METHOD Save() VIRTUAL
> METHOD Report() VIRTUAL
> ...
> ENDCLASS
>
> Method Load() Class TFormBase
> //hago lo que van a hacer en comun el 90% de los mantenimientos
> Return ( Nil)
>
> CLASS TClientes FROM TFormBase
>
> METHOD FormInitialize( oSender )
> METHOD Load()
> METHOD Save()
> METHOD Report()
>
> ENDCLASS
>
> Method Load() Class TClientes
> //en este metodo hago cosas distintas a los del load que tiene la clase
> tFormBase
> Return ( Nil)
>
> Gracias.
> Saludos
> Ramón Zea
>
>

Saludos:
Ya que dices que hicistes algo por el estilo a lo que necesito te
importaría enviarme algo de lo que hicistes a mi correo que es
JRCPOLI@terra.es te lo arradeceré ya que ahorraré tiempo.
José Ramón Castro.
"Ramón Zea" <zeasoftware@hotmail.com> escribió en el mensaje
news:[email=42e01936@ozsrvnegro.ozlan.local...]42e01936@ozsrvnegro.ozlan.local...[/email]
> yo hice eso exactamente, y en unos minutos armo el mantenimiento de un
> catalogo de datos.
>
> El asunto es que tengo problemas al querer usarlo en MDI, y en lo cual me
> esta hechando la mano F.Gimenez.
>
> En uno de los mensajes anteriores por ahi postee el ejemplo.
>
> Saludos.
> ramon zea
>
>

Pues mejor todabía de esa forma el código es reutilizable, gracias por la
observación, queda má claro aun.
Saludos.
"José Lalín" <dezac@corevia.com> escribió en el mensaje
news:42e163f9$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>
> Ramón,
>
>> Con la opcion VIRTUAL, puedo hacer los metodos y luego reescribirlos en
>> otra
>> clase?
>
> Sí, por supuesto. Incluso puedes poner código en el método de la clase
> padre y llamarlo desde la hija.
>
> Tu mismo código con algunas modificaciones:
>
> Method Load() Class TClientes
>
> <TuCodigo>
>
> /* Ejecutar el código de TFormBase:Load()
> */
> Super:Load()
>
> <MasCodigo>
>
> Return Nil
>
> Saludos,
> José Lalín

Con la opcion VIRTUAL, puedo hacer los metodos y luego reescribirlos en otra
clase?
algo asi:
CLASS TFormBase FROM TForm
COMPONENT ...
...
METHOD FormInitialize( oSender )
METHOD Load() VIRTUAL
METHOD Save() VIRTUAL
METHOD Report() VIRTUAL
...
ENDCLASS
Method Load() Class TFormBase
//hago lo que van a hacer en comun el 90% de los mantenimientos
Return ( Nil)
CLASS TClientes FROM TFormBase
METHOD FormInitialize( oSender )
METHOD Load()
METHOD Save()
METHOD Report()
ENDCLASS
Method Load() Class TClientes
//en este metodo hago cosas distintas a los del load que tiene la clase
tFormBase
Return ( Nil)
Gracias.
Saludos
Ramón Zea

Lo voy a adaptar a como lo explica F.G. aqui, ya que se cuelga, aunque ya me
apoyo en muchas cosas, aun se me bloquea y marca errores, una vez a aptado
lo posteo para que lo tomes, o te lo mando al privado.
Saludos.
Ramón Zea
ramonzea@yahoo.com
"José R.Castro" <JRCPOLI@terra.es> escribió en el mensaje
news:42e167d1$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Saludos:
> Ya que dices que hicistes algo por el estilo a lo que necesito te
> importaría enviarme algo de lo que hicistes a mi correo que es
> JRCPOLI@terra.es te lo arradeceré ya que ahorraré tiempo.
>
> José Ramón Castro.
>
> "Ramón Zea" <zeasoftware@hotmail.com> escribió en el mensaje
> news:[email=42e01936@ozsrvnegro.ozlan.local...]42e01936@ozsrvnegro.ozlan.local...[/email]
>> yo hice eso exactamente, y en unos minutos armo el mantenimiento de un
>> catalogo de datos.
>>
>> El asunto es que tengo problemas al querer usarlo en MDI, y en lo cual me
>> esta hechando la mano F.Gimenez.
>>
>> En uno de los mensajes anteriores por ahi postee el ejemplo.
>>
>> Saludos.
>> ramon zea
>>
>>
>
>

José Ramón,
> Vale aqui va como esta definido actualmente el ejemplo en el Method.
Ok, gracias. Ya he visto la diferencia, aunque a mí no me ocurre.
> Otra cosa que puede ocurrir es que cuando se instale la release 4 sin
> borrar
> la anterior versión no modifique los samples que ya tengas y que lo suyo
> sea
> hacer una instalación nueva cuidando de mover los directorios en la que
> tengas aplicaciones o instalarla en otro directorio cosa que yo no he
> hecho.
No debe influir para nada. No obstante, lo que sí hay que hacer es
recompilar completamente todos los proyectos ya que ha habido cambios en
xHarbour que obligan a esto.
> Desde Cartagena (Murcia)
Hombre... ultimamente estamos haciendo reuniones con cierta frecuencia en
Murcia. Si quieres te podemos avisar para la próxima por si puedes y quieres
asistir.
--
Un saludo,
José F. Giménez

José Ramón y Ramón,
en realidad sí se puede poner código en ambas clases, padre e hija. En ese
caso, lo que se ejecuta siempre es el código de la clase hija, y si queremos
que se ejecute el código de la clase padre sólo hay que llamar al método
super. P.ej.:
METHOD Save() CLASS TFormBase
// Aqui se desahilitan los botones de ok y cancel de la toolbar
RETURN Nil
METHOD Save() CLASS TClientes
// Primero guardamos la informacion y realizamos
// las tareas propias del mantenimiento de clientes
....
// Y ahora llamamos al metodo super para que deshabilite
// los botones de ok y cancel
Super:Save()
RETURN Nil
Incluso se podría poner simplemente:
METHOD Save() CLASS TClientes
...
RETURN Super:Save()
Este tipo de construcciones es muy muy habitual en cualquier sistema POO, es
más, Xailer está plagado de ellas por todos lados.
--
Un saludo,
José F. Giménez

Saludos:
Encantado de que me avises si haceís halgo por aquí, iré con sumo gusto.
José Ramón Castro
JRCPOLI@terra.es
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:42e2168b$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> José Ramón,
>
>> Vale aqui va como esta definido actualmente el ejemplo en el Method.
>
> Ok, gracias. Ya he visto la diferencia, aunque a mí no me ocurre.
>
>
>> Otra cosa que puede ocurrir es que cuando se instale la release 4 sin
>> borrar
>> la anterior versión no modifique los samples que ya tengas y que lo suyo
>> sea
>> hacer una instalación nueva cuidando de mover los directorios en la que
>> tengas aplicaciones o instalarla en otro directorio cosa que yo no he
>> hecho.
>
> No debe influir para nada. No obstante, lo que sí hay que hacer es
> recompilar completamente todos los proyectos ya que ha habido cambios en
> xHarbour que obligan a esto.
>
>
>> Desde Cartagena (Murcia)
>
> Hombre... ultimamente estamos haciendo reuniones con cierta frecuencia en
> Murcia. Si quieres te podemos avisar para la próxima por si puedes y
> quieres
> asistir.
>
>
> --
> Un saludo,
>
> José F. Giménez
>
>

Saludos:
He configurado el formulario principal tal como me comestates y ahora
estoy con los PRGS solos de cada base de datos, el problema es que un novato
como yo con Xailer no ha sabido implementar desde el PRG las columnas del
formulario lo demás hasta donde puedo alcanzar sin las columnas funciona
correctamente, paso uno de los PRGS para si alguno es tan amable y me saca
del lio de las columnas, tienen que estar configuradas igual que estan en el
Report.
/*
* Proyecto: Concurso
* Fichero: Federacion.prg
* Descripción: Mantenimiento Fichero de Federaciones
* Autor: José Ramón Castro Polinio
* Fecha: 27/07/2005
*/
#include "Xailer.ch"
#include "report.ch"
CLASS TFederac FROM TFormMant
METHOD FormInitialize( oSender )
METHOD AddNew( oSender )
METHOD Edit( oSender )
METHOD Report()
METHOD DataSetOpen( oSender )
ENDCLASS
//---------------------------------------------------------- -------------
METHOD FormInitialize( oSender ) CLASS TFederac
Local oCol
// Titulo del Formulario
oSender:cText := "Mantenimiento de Federaciones"
// Inicializa la base de datos a Utilizar
::oDataSet:cName := 'C:XailerSamplesConcursoBasesFederac.dbf'
::oDataSet:lOpen := .T.
// Aqui debían configurarse las columnas
// del Browser, según estan en el Report
// he puesto esto porque no da error y se puede
// trabajar con el resto del formulario.
oSender:oDBw := ::oDataSet
RETURN Super:FormInitialize( oSender )
//---------------------------------------------------------- -------------
METHOD AddNew( oSender ) CLASS TFederac
Super:AddNew(TFormFedNew():New( Self ) )
RETURN Nil
//---------------------------------------------------------- -------------
METHOD Edit( oSender ) CLASS TFederac
Super:Edit(TFormFedNew():New( Self ) )
RETURN Nil
//---------------------------------------------------------- -------------
METHOD Report() CLASS TFederac
local oReport
// Browser al principio
::oDBw:GoTop()
REPORT oReport TITLE "Tabla Federación" PREVIEW
COLUMN OF oReport ;
TITLE "Nº " ;
DATA ::oDataSet:N_FED
COLUMN OF oReport ;
TITLE "Nombre" ;
DATA ::oDataSet:Nomb_Fed
COLUMN OF oReport ;
TITLE "Población" ;
DATA ::oDataSet:Poblacion
RUN REPORT oReport
// Vuelve a posicionar el Browser
::oDBw:GoTop()
RETURN Nil
"José R.Castro" <JRCPOLI@terra.es> escribió en el mensaje
news:[email=42e2c067@ozsrvnegro.ozlan.local...]42e2c067@ozsrvnegro.ozlan.local...[/email]
> Saludos:
> Encantado de que me avises si haceís halgo por aquí, iré con sumo
> gusto.
>
> José Ramón Castro
> JRCPOLI@terra.es
>
> "Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
> news:42e2168b$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>> José Ramón,
>>
>>> Vale aqui va como esta definido actualmente el ejemplo en el Method.
>>
>> Ok, gracias. Ya he visto la diferencia, aunque a mí no me ocurre.
>>
>>
>>> Otra cosa que puede ocurrir es que cuando se instale la release 4 sin
>>> borrar
>>> la anterior versión no modifique los samples que ya tengas y que lo suyo
>>> sea
>>> hacer una instalación nueva cuidando de mover los directorios en la que
>>> tengas aplicaciones o instalarla en otro directorio cosa que yo no he
>>> hecho.
>>
>> No debe influir para nada. No obstante, lo que sí hay que hacer es
>> recompilar completamente todos los proyectos ya que ha habido cambios en
>> xHarbour que obligan a esto.
>>
>>
>>> Desde Cartagena (Murcia)
>>
>> Hombre... ultimamente estamos haciendo reuniones con cierta frecuencia en
>> Murcia. Si quieres te podemos avisar para la próxima por si puedes y
>> quieres
>> asistir.
>>
>>
>> --
>> Un saludo,
>>
>> José F. Giménez
>>
>>
>
>

José Ramón,
> He configurado el formulario principal tal como me comestates y ahora
> estoy con los PRGS solos de cada base de datos, el problema es que un
> novato
> como yo con Xailer no ha sabido implementar desde el PRG las columnas del
> formulario lo demás hasta donde puedo alcanzar sin las columnas funciona
> correctamente, paso uno de los PRGS para si alguno es tan amable y me saca
> del lio de las columnas, tienen que estar configuradas igual que estan en
> el
> Report.
puedes crear un formulario con el browse, añadir las columnas desde el mismo
IDE, y después abrir el fichero .xfm para ver cómo se crean.
--
Un saludo,
José F. Giménez

Saludos:
No sé si te acuerdas de que se trata de hacer todos los mantenimientos
con el mismo formulario y los PRGS solo contienen los metodos que no son
comunes o que cambian, en este caso el formulario es el del ejemplo del
DataControl - ejemplo dos, por lo tanto el Browser está creado en el
formulario princial, lo que hay que hacer en el PRG es solo configurar las
columnas, para ello he empleado el mismo metodo que está implementado como
si las columnas fueran fijas en el Browser del formulario principal así:
WITH OBJECT ::oDBw := TDBBrwColumn():New( ::oDBw )
:cHeader := "Nº Fed."
:nClrText := ClMenuText
:nWidth := 57
:oDataField := "N_FED"
:Create()
END
Esto no funciona, no da error al complilar ni al linkarlo pero al ejecutarlo
sí, algo le falta o no llamo al oDBw que es el TDBBrowse del principal. Si
desactivo esto el formulario se muestra pero claro sin que el Browse tenga
ni una columna, pero si tiene datos ya que si le doy al botón de Editar me
muestra el primer registro de la base de datos.
Solo me falta esto para terminar todos los mantenimientos de las bases de
datos saber implementar las columnas del Browse.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:42e8a0da$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> José Ramón,
>
>> He configurado el formulario principal tal como me comestates y ahora
>> estoy con los PRGS solos de cada base de datos, el problema es que un
>> novato
>> como yo con Xailer no ha sabido implementar desde el PRG las columnas del
>> formulario lo demás hasta donde puedo alcanzar sin las columnas funciona
>> correctamente, paso uno de los PRGS para si alguno es tan amable y me
>> saca
>> del lio de las columnas, tienen que estar configuradas igual que estan en
>> el
>> Report.
>
> puedes crear un formulario con el browse, añadir las columnas desde el
> mismo
> IDE, y después abrir el fichero .xfm para ver cómo se crean.
>
> --
> Un saludo,
>
> José F. Giménez
>
>

José,
fí­jate en esta lí­nea:
> WITH OBJECT ::oDBw := TDBBrwColumn():New( ::oDBw )
estás asignando el objeto columna al browse, seguramente por eso se
produce el error.
Hazlo así­ si no quieres guardar la columna en ninguna variable:
WITH OBJECT TDBBrwColumn():New( ::oDBw )
O así­ si quieres guardar el objeto columna en una variable:
WITH OBJECT oColumna1 := TDBBrwColumn():New( ::oDBw )
Saludos,
José Lalí­n

Efectivamente estaba haciendo una cosa incorrecta pero ahora me sale la
columna pero vacia, esto es el browser no se le visualiza el contenido, pero
lo tiene porque se pueden navegar con los botones, y dar a editar y sale su
contenido.
Ha alguien le ha pasado que haya puesto las columnas pero no se vea el
contenido y la barra de navegación de los registros.
"José Lalín" <dezac@corevia.com> escribió en el mensaje
news:[email=42e92f6c@ozsrvnegro.ozlan.local...]42e92f6c@ozsrvnegro.ozlan.local...[/email]
>
> José,
>
> fíjate en esta línea:
>
>> WITH OBJECT ::oDBw := TDBBrwColumn():New( ::oDBw )
>
> estás asignando el objeto columna al browse, seguramente por eso se
> produce el error.
>
> Hazlo así si no quieres guardar la columna en ninguna variable:
>
> WITH OBJECT TDBBrwColumn():New( ::oDBw )
>
> O así si quieres guardar el objeto columna en una variable:
>
> WITH OBJECT oColumna1 := TDBBrwColumn():New( ::oDBw )
>
> Saludos,
> José Lalín

José Ramón,
envíame el proyecto y lo reviso. Es muy posible que sea alguna cosa muy
sencilla, pero que no sea fácil verla.
--
Un saludo,
José F. Giménez

Bien a tú correo privado te envio el proyecto en la fase que está
actualmente.
Aquí pongo dos ficheros uno el Formulario General y otro un PRG, con este
ejemplo se puede hacer cualquier mantenimiento de las bases auxiliares de
una aplicación.
José Ramón Castro Polinio
JRCPOLI@terra.es
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:[email=42e9e3a8@ozsrvnegro.ozlan.local...]42e9e3a8@ozsrvnegro.ozlan.local...[/email]
> José Ramón,
>
> envíame el proyecto y lo reviso. Es muy posible que sea alguna cosa muy
> sencilla, pero que no sea fácil verla.
>
> --
> Un saludo,
>
> José F. Giménez
>
>


Attached files Federac.prg (3.5 KB)Â FormMant.prg (6.2 KB)Â

José Ramón,
> Bien a tú correo privado te envio el proyecto en la fase que está
> actualmente.
Sí, lo he visto, pero faltan los ficheros de datos. Envíamelos para poder
probarlo.
--
Un saludo,
José F. Giménez

Ramón:
He visto lo que hicistes, pero creo que utilizas un formulario para cada
fichero que quieres mantener, yo lo que he realizado es un solo un
formulario y los demas se mantienen con solo PRGS.
Si no es así perdona pero es lo que yo he entendido.
José Ramón Castro Polinio
JRCPOLI@terra.es
"Ramón Zea" <zeasoftware@hotmail.com> escribió en el mensaje
news:[email=42ebf042@ozsrvnegro.ozlan.local...]42ebf042@ozsrvnegro.ozlan.local...[/email]
> si te fijas por ahi postee como me quedo la clase para mantenimientos, me
> esta corriendo excelentemente.
>
> Saludos.
> Ramón Zea
>
>

José:
De acuerdo tienes razón no comprimí los ficheros, vale miro lo que te he
enviado y te mando los datos.
José Ramón Castro Polinio
JRCPOLI@terra.es
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje
news:42ebd388$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> José Ramón,
>
>> Bien a tú correo privado te envio el proyecto en la fase que está
>> actualmente.
>
> Sí, lo he visto, pero faltan los ficheros de datos. Envíamelos para poder
> probarlo.
>
> --
> Un saludo,
>
> José F. Giménez
>
>