#ifdef, #define

[macrosys]

Hola foro
Utilizando el ide agregué un tmenu a un tform y le fui poniendo las
diferentes opciones utilizando el inspector de objetos, ahora bien,
quiero que algunas de las opciones del menú aparezcan o no, según los
#DEFINE que coloque en un fichero de cabecera, de esta manera:
MIFICHERO.CH
*#DEFINE VERSION1
#DEFINE VERSION2
#ifdef VERSION1
#DEFINE VENTAS
#endif
#ifdef VERSION2
#DEFINE VENTAS
#DEFINE STOCK
#endif
¿Es posible hacer eso?, ¿hay otras formas de hacerlo?
La idea es hacer un menú "genérico" que me sirva para varias versiones
de mi aplicación, conforme a los #define que estén en el archivo de
cabecera.
Les agradezco desde ya la ayuda.
Saludos
Daniel.

[zeasoftware]

Por que no utilizas
#ifdef FACTURAS
<opcion>:lEnabled := .f.
#endif
Se me ocurre, igual voy a hacer este proceso.
Saludos.
--
Ramón Zea
ramonzea@yahoo.com
http://www.paginasprodigy.com/zeasoft/

[jfgimenez]

Daniel,
> La idea es hacer un menú "genérico" que me sirva para varias versiones de
> mi aplicación, conforme a los #define que estén en el archivo de cabecera.
entonces la mejor forma de hacerlo es usando los comandos de creación de
menú. Algo así:
MENU ::oMenu1
#ifdef ...
MENUITEM "Uno"
MENU
MENUITEM "Opcion1" ACTION ...
...
ENDMENU
#else
MENUITEM "Dos"
MENU
MENUITEM "Opcion2" ACTION ...
...
ENDMENU
#endif
ENDMENU
El ejemplo samplesvisor tiene un menú creado con comandos que puedes
revisar.
--
Un saludo,
José F. Giménez

[macrosys]

José:
Esta muy claro el ejemplo, pero me gustarí­a hacer el siguiente
comentario solo para ver si voy entendiendo bien: cuando necesitamos
hacer un diseño (en este caso de un menú) algo personalizado o
condicionado, es preferible utilizar el editor de código en vez del IDE,
y apoyarnos en las enormes ventajas del IDE, cuando esas ventajas son
suficientes para nuestro proyecto.
Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero
pensé (y seguramente en forma equivocada) que luego de hacer el diseño
de lo necesitamos con la ayuda del IDE, podí­amos ir y editar algún
archivo fuente generado por éste, en el cual terminemos "a mano" los
detalles que necesitemos. Por lo que voy leyendo en el manual los
archivos generados automáticamente son los .XFM y esos no hay que tocarlos.
¿Voy bien?
Saludos
Daniel.
PD: quiero agradecer también las ideas que dio Ramón Zea
Jose F. Gimenez escribió:
> Daniel,
>
>> La idea es hacer un menú "genérico" que me sirva para varias versiones de
>> mi aplicación, conforme a los #define que estén en el archivo de cabecera.
>
> entonces la mejor forma de hacerlo es usando los comandos de creación de
> menú. Algo así­:
>
> MENU ::oMenu1
> #ifdef ...
> MENUITEM "Uno"
> MENU
> MENUITEM "Opcion1" ACTION ...
> ...
> ENDMENU
> #else
> MENUITEM "Dos"
> MENU
> MENUITEM "Opcion2" ACTION ...
> ...
> ENDMENU
> #endif
> ENDMENU
>
> El ejemplo samplesvisor tiene un menú creado con comandos que puedes
> revisar.
>
>

[jfgimenez]

Daniel,
> Esta muy claro el ejemplo, pero me gustaría hacer el siguiente comentario
> solo para ver si voy entendiendo bien: cuando necesitamos hacer un diseño
> (en este caso de un menú) algo personalizado o condicionado, es preferible
> utilizar el editor de código en vez del IDE, y apoyarnos en las enormes
> ventajas del IDE, cuando esas ventajas son suficientes para nuestro
> proyecto.
Ciertamente el IDE es una ayuda enorme a la tarea de programar, pero por
supuesto no puede hacerlo todo; y menos mal, porque si no dejaríamos de
trabajar los programadores y ocuparían nuestro lugar los diseñadores
En el caso de los menúes, te he aconsejado que los hagas por código, ya que
es muy sencillo y tienes más flexibilidad. No obstante, también podrías
haberlo hecho todo con el IDE, nombrando (rellenando su propiedad cVarName)
aquellas opciones que tengas que modificar por código, y después hacer los
cambios que necesites en el evento OnInitialize. Pero como te he dicho, creo
que al final es más sencillo y más fácil de mantener si lo haces todo por
código.
> Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero pensé
> (y seguramente en forma equivocada) que luego de hacer el diseño de lo
> necesitamos con la ayuda del IDE, podíamos ir y editar algún archivo
> fuente generado por éste, en el cual terminemos "a mano" los detalles que
> necesitemos. Por lo que voy leyendo en el manual los archivos generados
> automáticamente son los .XFM y esos no hay que tocarlos.
>
> ¿Voy bien?
Exactamente. Los .xfm son los que contienen el código que genera el IDE, y
no se deben tocar a mano, ya que podría provocar que el IDE diera errores al
volver a cargar el formulario. Hasta ahora, prácticamente todo se puede
hacer desde el IDE y cambiando lo que necesitemos desde algún evento
(OnInitialize, OnCreate, etc.); e incluso se puede hacer por código aquello
que se complique demasiado, como en el caso anterior. Pero de una forma u
otra, los ficheros .xfm no conviene modificarlos a mano.
--
Un saludo,
José F. Giménez

[macrosys]

Jose:
Muchas Gracias.
Excelente aclaración.
Daniel.
Jose F. Gimenez escribió:
> Daniel,
>
>> Esta muy claro el ejemplo, pero me gustarí­a hacer el siguiente comentario
>> solo para ver si voy entendiendo bien: cuando necesitamos hacer un diseño
>> (en este caso de un menú) algo personalizado o condicionado, es preferible
>> utilizar el editor de código en vez del IDE, y apoyarnos en las enormes
>> ventajas del IDE, cuando esas ventajas son suficientes para nuestro
>> proyecto.
>
> Ciertamente el IDE es una ayuda enorme a la tarea de programar, pero por
> supuesto no puede hacerlo todo; y menos mal, porque si no dejarí­amos de
> trabajar los programadores y ocuparí­an nuestro lugar los diseñadores
>
> En el caso de los menúes, te he aconsejado que los hagas por código, ya que
> es muy sencillo y tienes más flexibilidad. No obstante, también podrí­as
> haberlo hecho todo con el IDE, nombrando (rellenando su propiedad cVarName)
> aquellas opciones que tengas que modificar por código, y después hacer los
> cambios que necesites en el evento OnInitialize. Pero como te he dicho, creo
> que al final es más sencillo y más fácil de mantener si lo haces todo por
> código.
>
>
>> Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero pensé
>> (y seguramente en forma equivocada) que luego de hacer el diseño de lo
>> necesitamos con la ayuda del IDE, podí­amos ir y editar algún archivo
>> fuente generado por éste, en el cual terminemos "a mano" los detalles que
>> necesitemos. Por lo que voy leyendo en el manual los archivos generados
>> automáticamente son los .XFM y esos no hay que tocarlos.
>>
>> ¿Voy bien?
>
> Exactamente. Los .xfm son los que contienen el código que genera el IDE, y
> no se deben tocar a mano, ya que podrí­a provocar que el IDE diera errores al
> volver a cargar el formulario. Hasta ahora, prácticamente todo se puede
> hacer desde el IDE y cambiando lo que necesitemos desde algún evento
> (OnInitialize, OnCreate, etc.); e incluso se puede hacer por código aquello
> que se complique demasiado, como en el caso anterior. Pero de una forma u
> otra, los ficheros .xfm no conviene modificarlos a mano.
>

[macrosys]

/*
* Proyecto: WVENTAS
* Fichero: Form1.prg
* Descripción:
* Autor:
* Fecha: 21/05/2006
*/
#include "Xailer.ch"
#include "Module1.ch"
CLASS TForm1 FROM TForm
COMPONENT oStatusBar1
COMPONENT oStatusBar1Panel1
METHOD CreateForm()
METHOD FormInitialize(oSender)
ENDCLASS
#include "Form1.xfm"
//---------------------------------------------------------- --------------------
METHOD FormInitialize( oSender ) CLASS TForm1
LOCAL oMenu
MENU oMenu
MENUITEM "&Cuentas"
MENU
MENUITEM "&Clientes"
MENUITEM "&Proveedores"
SEPARATOR
MENUITEM "&Bancos"
MENUITEM "&Financieras"
#ifdef OPTICAS
SEPARATOR
MENUITEM "F&ichas Clínicas"
#endif OPTICAS
ENDMENU
MENUITEM "&Ventas"
MENU
MENUITEM "&Facturación"
MENUITEM "&Cobranza"
MENUITEM "C&aja"
MENUITEM "Ci&erre de Caja"
SEPARATOR
MENUITEM "Cotizaciones"
ENDMENU
MENUITEM "C&ompras"
MENU
MENUITEM "&Ingreso de Compras"
MENUITEM "&Pagos a Proveedores"
MENUITEM "O&rdenes de Pago"
MENUITEM "&Ordenes de Compra"
ENDMENU
MENUITEM "&Bancos y Cheques"
MENU
MENUITEM "&Movimientos"
MENUITEM "&Estado de Cuenta"
SEPARATOR
MENUITEM "&Cartera de Cheques"
MENUITEM "&Traspaso de Cheques"
MENUITEM "&Depósito Automático"
ENDMENU
MENUITEM "&Stock"
MENU
MENUITEM "&Artículos"
MENU
MENUITEM "&Materia Prima"
MENUITEM "&Listas de precios"
MENUITEM "&Fórmulas"
MENUITEM "&Códigos Alternativos"
MENUITEM "Códigos &Sustituto"
MENUITEM "Cám&bios de código"
MENUITEM "Combos de Artíc&ulos"
MENUITEM "&Eliminación Global"
ENDMENU
MENUITEM "Remitos de &Entrada"
MENUITEM "Remitos de &Salida"
MENUITEM "Recuentos"
MENUITEM "Inventarios"
ENDMENU
MENUITEM "&Fin" ACTION ::Close()
ENDMENU
::oMenu := oMenu
RETURN Nil
--

[macrosys]

José:
Estoy tratando de hacer el menú por los dos métodos (a mano y con el
IDE), y veo que el IDE me aporta mucho de lo que aún no se, por ejemplo
veo todos los eventos, propiedades, etc. que existen para cada clase,
componente o control que voy utilizando
¿como seria con el IDE?, ¿puedo ver un pequeño ejemplo?.
Estoy tratando de hacerlo basándome en el ejemplo "MENUS" pero no me
sale, lo que estoy poniendo es esto:
METHOD Form1Initialize( oSender ) CLASS TForm1
#define PRUEBA
#ifdef PRUEBA
:oMenuItem1:lEnabled := .F.
#endif PRUEBA
RETURN Nil
Muchas Gracias
Daniel.
Jose F. Gimenez escribió:
> Daniel,
>
>> Esta muy claro el ejemplo, pero me gustarí­a hacer el siguiente comentario
>> solo para ver si voy entendiendo bien: cuando necesitamos hacer un diseño
>> (en este caso de un menú) algo personalizado o condicionado, es preferible
>> utilizar el editor de código en vez del IDE, y apoyarnos en las enormes
>> ventajas del IDE, cuando esas ventajas son suficientes para nuestro
>> proyecto.
>
> Ciertamente el IDE es una ayuda enorme a la tarea de programar, pero por
> supuesto no puede hacerlo todo; y menos mal, porque si no dejarí­amos de
> trabajar los programadores y ocuparí­an nuestro lugar los diseñadores
>
> En el caso de los menúes, te he aconsejado que los hagas por código, ya que
> es muy sencillo y tienes más flexibilidad. No obstante, también podrí­as
> haberlo hecho todo con el IDE, nombrando (rellenando su propiedad cVarName)
> aquellas opciones que tengas que modificar por código, y después hacer los
> cambios que necesites en el evento OnInitialize. Pero como te he dicho, creo
> que al final es más sencillo y más fácil de mantener si lo haces todo por
> código.
>
>
>> Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero pensé
>> (y seguramente en forma equivocada) que luego de hacer el diseño de lo
>> necesitamos con la ayuda del IDE, podí­amos ir y editar algún archivo
>> fuente generado por éste, en el cual terminemos "a mano" los detalles que
>> necesitemos. Por lo que voy leyendo en el manual los archivos generados
>> automáticamente son los .XFM y esos no hay que tocarlos.
>>
>> ¿Voy bien?
>
> Exactamente. Los .xfm son los que contienen el código que genera el IDE, y
> no se deben tocar a mano, ya que podrí­a provocar que el IDE diera errores al
> volver a cargar el formulario. Hasta ahora, prácticamente todo se puede
> hacer desde el IDE y cambiando lo que necesitemos desde algún evento
> (OnInitialize, OnCreate, etc.); e incluso se puede hacer por código aquello
> que se complique demasiado, como en el caso anterior. Pero de una forma u
> otra, los ficheros .xfm no conviene modificarlos a mano.
>

[ignacio]

Daniel,
Ejemplo de menú a través del IDE:
SamplesMenus
Ejemplo de menú creado manualmente:
SamplesDataControlsDbfData2
Saludos,
"Daniel Du Pré" <macrosys@adinet.com.uy> escribió en el mensaje
news:[email=44a87adb@news.xailer.com...]44a87adb@news.xailer.com...[/email]
> José:
> Estoy tratando de hacer el menú por los dos métodos (a mano y con el IDE),
> y veo que el IDE me aporta mucho de lo que aún no se, por ejemplo veo
> todos los eventos, propiedades, etc. que existen para cada clase,
> componente o control que voy utilizando
>
> ¿como seria con el IDE?, ¿puedo ver un pequeño ejemplo?.
> Estoy tratando de hacerlo basándome en el ejemplo "MENUS" pero no me sale,
> lo que estoy poniendo es esto:
>
> METHOD Form1Initialize( oSender ) CLASS TForm1
>
> #define PRUEBA
>
> #ifdef PRUEBA
> :oMenuItem1:lEnabled := .F.
> #endif PRUEBA
>
> RETURN Nil
>
>
> Muchas Gracias
> Daniel.
>
> Jose F. Gimenez escribió:
>> Daniel,
>>
>>> Esta muy claro el ejemplo, pero me gustaría hacer el siguiente
>>> comentario solo para ver si voy entendiendo bien: cuando necesitamos
>>> hacer un diseño (en este caso de un menú) algo personalizado o
>>> condicionado, es preferible utilizar el editor de código en vez del IDE,
>>> y apoyarnos en las enormes ventajas del IDE, cuando esas ventajas son
>>> suficientes para nuestro proyecto.
>>
>> Ciertamente el IDE es una ayuda enorme a la tarea de programar, pero por
>> supuesto no puede hacerlo todo; y menos mal, porque si no dejaríamos de
>> trabajar los programadores y ocuparían nuestro lugar los diseñadores
>>
>> En el caso de los menúes, te he aconsejado que los hagas por código, ya
>> que es muy sencillo y tienes más flexibilidad. No obstante, también
>> podrías haberlo hecho todo con el IDE, nombrando (rellenando su propiedad
>> cVarName) aquellas opciones que tengas que modificar por código, y
>> después hacer los cambios que necesites en el evento OnInitialize. Pero
>> como te he dicho, creo que al final es más sencillo y más fácil de
>> mantener si lo haces todo por código.
>>
>>
>>> Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero
>>> pensé (y seguramente en forma equivocada) que luego de hacer el diseño
>>> de lo necesitamos con la ayuda del IDE, podíamos ir y editar algún
>>> archivo fuente generado por éste, en el cual terminemos "a mano" los
>>> detalles que necesitemos. Por lo que voy leyendo en el manual los
>>> archivos generados automáticamente son los .XFM y esos no hay que
>>> tocarlos.
>>>
>>> ¿Voy bien?
>>
>> Exactamente. Los .xfm son los que contienen el código que genera el IDE,
>> y no se deben tocar a mano, ya que podría provocar que el IDE diera
>> errores al volver a cargar el formulario. Hasta ahora, prácticamente todo
>> se puede hacer desde el IDE y cambiando lo que necesitemos desde algún
>> evento (OnInitialize, OnCreate, etc.); e incluso se puede hacer por
>> código aquello que se complique demasiado, como en el caso anterior. Pero
>> de una forma u otra, los ficheros .xfm no conviene modificarlos a mano.
>>

[zeasoftware]

yo hago esto y funciona bien.
#ifdef _NOTA_DE_CREDITO_
MENUITEM "&Notas de Crédito" ACTION TNotasCredito():New( self ):Show()
#endif
--
Ramón Zea
ramonzea@yahoo.com
http://www.paginasprodigy.com/zeasoft/
--

[macrosys]

Ramon:
Muchas Gracias ahora si me funciona.
Lo que sucedí­a (y no tengo idea porque) es que al poner el #endif, la
linea vertical que aparece a la izquierda del código que se va
escribiendo y que comienza con un cuadradito con el signo + dentro para
indicar inicio y fin de un método, llegaba hasta el #endif en lugar de
llegar hasta el "Return Nil", entonces al compilar sin error no me daba
cuenta que estaba "haciendo mal". El hecho es que (por casualidad) llevé
el cursor hasta donde termina el método FormInitialize que tengo creado
y en ese momento dicha linea se prolongó hasta el "Return Nil", luego
compile y anduvo perfecto.¿?
Saludos
Daniel.
Ramón Zea escribió:
> yo hago esto y funciona bien.
>
>
> *#ifdef _NOTA_DE_CREDITO_
> MENUITEM "&Notas de Crédito" ACTION TNotasCredito():New( self
> ):Show()
> #endif*
>
> --
> Ramón Zea
> ramonzea@yahoo.com <mailto:ramonzea@yahoo.com>
>
> http://www.paginasprodigy.com/zeasoft/

[macrosys]

Ignacio:
Creo que formule mal la pregunta; la idea del "ejemplo con el IDE" es
ver como se utiliza una clausula #ifdef en un menú creado con el IDE y
en SamplesMenus no encuentro donde está.
Agradecerí­a mucho si me puede indicar donde buscarlo o si me puede
enviar un pequeño .prg que lo haga.
Saludos
Daniel.
Ignacio Ortiz de Zúñiga escribió:
> Daniel,
>
> Ejemplo de menú a través del IDE:
> SamplesMenus
>
> Ejemplo de menú creado manualmente:
> SamplesDataControlsDbfData2
>
> Saludos,
>
> "Daniel Du Pré" <macrosys@adinet.com.uy> escribió en el mensaje
> news:[email=44a87adb@news.xailer.com...]44a87adb@news.xailer.com...[/email]
>> José:
>> Estoy tratando de hacer el menú por los dos métodos (a mano y con el IDE),
>> y veo que el IDE me aporta mucho de lo que aún no se, por ejemplo veo
>> todos los eventos, propiedades, etc. que existen para cada clase,
>> componente o control que voy utilizando
>>
>> ¿como seria con el IDE?, ¿puedo ver un pequeño ejemplo?.
>> Estoy tratando de hacerlo basándome en el ejemplo "MENUS" pero no me sale,
>> lo que estoy poniendo es esto:
>>
>> METHOD Form1Initialize( oSender ) CLASS TForm1
>>
>> #define PRUEBA
>>
>> #ifdef PRUEBA
>> :oMenuItem1:lEnabled := .F.
>> #endif PRUEBA
>>
>> RETURN Nil
>>
>>
>> Muchas Gracias
>> Daniel.
>>
>> Jose F. Gimenez escribió:
>>> Daniel,
>>>
>>>> Esta muy claro el ejemplo, pero me gustarí­a hacer el siguiente
>>>> comentario solo para ver si voy entendiendo bien: cuando necesitamos
>>>> hacer un diseño (en este caso de un menú) algo personalizado o
>>>> condicionado, es preferible utilizar el editor de código en vez del IDE,
>>>> y apoyarnos en las enormes ventajas del IDE, cuando esas ventajas son
>>>> suficientes para nuestro proyecto.
>>> Ciertamente el IDE es una ayuda enorme a la tarea de programar, pero por
>>> supuesto no puede hacerlo todo; y menos mal, porque si no dejarí­amos de
>>> trabajar los programadores y ocuparí­an nuestro lugar los diseñadores
>>>
>>> En el caso de los menúes, te he aconsejado que los hagas por código, ya
>>> que es muy sencillo y tienes más flexibilidad. No obstante, también
>>> podrí­as haberlo hecho todo con el IDE, nombrando (rellenando su propiedad
>>> cVarName) aquellas opciones que tengas que modificar por código, y
>>> después hacer los cambios que necesites en el evento OnInitialize. Pero
>>> como te he dicho, creo que al final es más sencillo y más fácil de
>>> mantener si lo haces todo por código.
>>>
>>>
>>>> Tengo claro que un IDE no "escribe" todo lo que queremos hacer, pero
>>>> pensé (y seguramente en forma equivocada) que luego de hacer el diseño
>>>> de lo necesitamos con la ayuda del IDE, podí­amos ir y editar algún
>>>> archivo fuente generado por éste, en el cual terminemos "a mano" los
>>>> detalles que necesitemos. Por lo que voy leyendo en el manual los
>>>> archivos generados automáticamente son los .XFM y esos no hay que
>>>> tocarlos.
>>>>
>>>> ¿Voy bien?
>>> Exactamente. Los .xfm son los que contienen el código que genera el IDE,
>>> y no se deben tocar a mano, ya que podrí­a provocar que el IDE diera
>>> errores al volver a cargar el formulario. Hasta ahora, prácticamente todo
>>> se puede hacer desde el IDE y cambiando lo que necesitemos desde algún
>>> evento (OnInitialize, OnCreate, etc.); e incluso se puede hacer por
>>> código aquello que se complique demasiado, como en el caso anterior. Pero
>>> de una forma u otra, los ficheros .xfm no conviene modificarlos a mano.
>>>
>
>

[macrosys]

Ramon:
Utilizo el cierre de la etiqueta solo por claridad al leer el fuente,
resulta que la aplicación que estoy migrando, tiene 15 añitos de vida y
te podrás imaginar que se ha personalizado bastante,es más, siempre me
hubiera gustado contar con algo así­:
#ifdef ALGO1 .AND. ALGO2
....
#endif
pero nunca lo vi y no se me ocurre como hacerlo.
Gracias
Saludos
Daniel.
Ramón Zea escribió:
> Eso solo lo hace el IDE, lo he notado desde que uso los #ifdef e incluso si
> usas un Return para romper la funcion antes del Return de la funcion, igual
> se pierde, pero tu programa debe funcinar bien.
>
> Una de las cosas que noto es que pones
> #ifdef ALGO
> #endif ALGO ---> ya no es necesario cerrar con la etiqueta define
>
> Saludos

[jlalin]

Daniel,
la directiva #ifdef puede anidarse y funciona como el IF..ENDIF, así­ que
para simular:
> #ifdef ALGO1 .AND. ALGO2
> ....
> #endif
No tienes más que hacer:
#ifdef ALGO1
#ifdef ALGO2 // para ALGO1 .AND ALGO2
...
#else // solo ALGO1
...
#endif
#endif
Saludos,
José Lalí­n

[zeasoftware]

Eso solo lo hace el IDE, lo he notado desde que uso los #ifdef e incluso si
usas un Return para romper la funcion antes del Return de la funcion, igual
se pierde, pero tu programa debe funcinar bien.
Una de las cosas que noto es que pones
#ifdef ALGO
#endif ALGO ---> ya no es necesario cerrar con la etiqueta define
Saludos
--
Ramón Zea
ramonzea@yahoo.com
http://www.paginasprodigy.com/zeasoft/