otro problemita al compilar con harbour

[Carlos Ortiz]

tení­a un bloque de código definido asi
bCode := < |oCheque|
oCheque:idestadocheque := oEstado:idestadocheque
oCheque:anulacion := fechaAnulacion
ret:=oCheque:Actualizar() >
....
.... y lo usaba así­
AEval(aCheques, bCode)
ahora al compilar salta este error
Compilando Cheques.prg...
C:ProyectoClasesSourceCheques.prg(173) Error E0030 Syntax error
"syntax error at '<'"
C:ProyectoClasesSourceCheques.prg(176) Error E0020 Incomplete
statement or unbalanced delimiters
1 Files, 0 Warnings, 2 Errors
Tiempo de compilación: 0.25s Tiempo de enlazado: 0s Tiempo total: 0.44s
Por lo demás la wiki me salvo de muchas preguntas!
Gracias!

[jfgimenez]

Carlos,
> tení­a un bloque de código definido asi
> bCode := < |oCheque|
> oCheque:idestadocheque := oEstado:idestadocheque
> oCheque:anulacion := fechaAnulacion
> ret:=oCheque:Actualizar() >
> ....
> .... y lo usaba así­
> AEval(aCheques, bCode)
>
> ahora al compilar salta este error
>
> Compilando Cheques.prg...
> C:ProyectoClasesSourceCheques.prg(173) Error E0030 Syntax error
> "syntax error at '<'"
> C:ProyectoClasesSourceCheques.prg(176) Error E0020 Incomplete
> statement or unbalanced delimiters
> 1 Files, 0 Warnings, 2 Errors
> Tiempo de compilación: 0.25s Tiempo de enlazado: 0s Tiempo total:
> 0.44s
Esa sintaxis corresponde a los "codeblocks extendidos" que tení­a
xHarbour, pero hasta donde yo sé, Harbour no los soporta. Tendrás que
cambiarlo por un bloque de código tradicional o por una funcional.
> Por lo demás la wiki me salvo de muchas preguntas!
Me alegro ;-)
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[Carlos Ortiz]

Por eso debe haber esto en xHarbour
#ifndef __XHARBOUR__
#xtranslate <|[]| => {||
#xcommand > [<*x*>] => }
#endif
muchas gracias José, va queriendo esto de compilar con X3, Harbour y MinGui

[Carlos Mora]

Hola Jose, tanto tiempo!
El 08/05/2014 9:32, Jose F. Gimenez escribió:> Carlos,
>
>> tení­a un bloque de código definido asi
>> bCode := < |oCheque|
>
> Esa sintaxis corresponde a los "codeblocks extendidos" que tení­a
> xHarbour, pero hasta donde yo sé, Harbour no los soporta. Tendrás que
> cambiarlo por un bloque de código tradicional o por una funcional.
Creo que Harbour si soporta codeblocks extendidos, solo que no utiliza
<|params| y > sino los mismos caracteres de siempre {|params| y }, pero
para que sea extendido la apertura debe ser lo ultimo de la lí­nea. Por
ejemplo, código extraí­do de un programa en uso:
oHC['Proveed']:bKeyDown:= {|nKey|
LOCAL cCodigo
IF nKey == VK_F2
cCodigo:= BrwBuscar( cDbfProveed, 'Codigo' )
IF !Empty( cCodigo )
oHC['Proveed']:oGet:VarPut( cCodigo )
oHC['Proveed']:Refresh()
ENDIF
ELSEIF nKey == VK_F3
FrmProveed( OPER_ALTA, cDbfProveed )
ENDIF
RETURN NIL
}
Una Closure en toda regla. Permite estructuras de control y demás
virguerí­as.
No se desde cuando, pero hace bastante, al menos un par de añitos.
Un saludo,
Carlos

[Carlos Mora]

El 21/05/2014 18:17, Carlos Mora escribió:
> No se desde cuando, pero hace bastante, al menos un par de añitos.
Al menos desde septiembre del 2011 ;)
http://harbouradvisor.blogspot.com.es/2011/09/extended-codeb locks.html

[Carlos Ortiz]

Gracias Carlos, lo tendré en cuenta!

[jfgimenez]

Hola Carlos,
> Hola Jose, tanto tiempo!
Sí­, es verdad que hace mucho que no hablamos (ni escribimos). Me alegro
de verte por aquí­ ;-)
> Creo que Harbour si soporta codeblocks extendidos, solo que no utiliza
> <|params| y > sino los mismos caracteres de siempre {|params| y },
> pero para que sea extendido la apertura debe ser lo ultimo de la
> lí­nea. Por ejemplo, código extraí­do de un programa en uso:
Gracias por la información. La verdad es que no lo sabí­a, y tampoco me
ha preocupado porque nunca los he usado. Yo opino que si una rutina no
"cabe" en un codeblock, entonces lo correcto es meterla en una
función/procedure, y si después lo necesitas como codeblock siempre
puedes llamarla desde ahí­. Vamos, que nunca he entendido la necesidad de
los "codeblock extendidos", pero bueno, tampoco los voy a criticar
porque puede que tengan una utilidad que yo no he visto.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[Carlos Mora]

El 22/05/2014 11:17, Jose F. Gimenez escribió:
> Hola Carlos,
> Sí­, es verdad que hace mucho que no hablamos (ni escribimos). Me alegro
> de verte por aquí­ ;-)
Siempre estoy, aunque calladito, pero siempre estoy :)
> ha preocupado porque nunca los he usado. Yo opino que si una rutina no
> "cabe" en un codeblock, entonces lo correcto es meterla en una
> función/procedure, y si después lo necesitas como codeblock siempre
> puedes llamarla desde ahí­. Vamos, que nunca he entendido la necesidad de
> los "codeblock extendidos", pero bueno, tampoco los voy a criticar
> porque puede que tengan una utilidad que yo no he visto.
La ventaja más interesante para mí­ es que puedes utilizar estructuras de
control, bucles, etc., dentro del codeblock. Y si, es cierto que mucho
código en un codeblock no es muy elegante, pero ponerlo en una función
separada tambien a veces implica poner en parámetros las variables que
para un codeblock son visibles por contexto.
Cuestión de gustos, je,
Un saludo,
Carlos

[jfgimenez]

Carlos,
> La ventaja más interesante para mí­ es que puedes utilizar estructuras
> de control, bucles, etc., dentro del codeblock. Y si, es cierto que
> mucho código en un codeblock no es muy elegante, pero ponerlo en una
> función separada tambien a veces implica poner en parámetros las
> variables que para un codeblock son visibles por contexto.
Pues tienes razón en eso de las variables. No habí­a caido en ello. Pero
claro, seguramente es porque en Xailer no hace falta para nada, jeje. En
Xailer, a diferencia de otros GUI, los eventos se desarrollan
normalmente como métodos de la clase formulario que estés manejando, y
por tanto puedes crear todas las propiedades que necesites dentro de la
clase, y las tendrás en ámbito no sólo en el evento correspondiente,
sino en cualquier otro método de la clase e incluso fuera de la clase
(según el ámbito que tengan declaradas).
Y supongo que coincidirás conmigo en que además de más elegante, el
código termina siendo más legible y mantenible ;-)
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

[Carlos Mora]

El 25/05/2014 11:45, Jose F. Gimenez escribió:
> Pues tienes razón en eso de las variables. No habí­a caido en ello. Pero
> claro, seguramente es porque en Xailer no hace falta para nada, jeje. En
> Xailer, a diferencia de otros GUI, los eventos se desarrollan
> normalmente como métodos de la clase formulario que estés manejando, y
> por tanto puedes crear todas las propiedades que necesites dentro de la
> clase, y las tendrás en ámbito no sólo en el evento correspondiente,
> sino en cualquier otro método de la clase e incluso fuera de la clase
> (según el ámbito que tengan declaradas).
>
> Y supongo que coincidirás conmigo en que además de más elegante, el
> código termina siendo más legible y mantenible ;-)
Y si, además, el que escribió el command tuvo la idea de usar la palabra
Self como nombre de variable/parámetro, imposibilitando usar los
comandos dentro de una clase sin que se generen conflictos, ni te cuento :P
Un saludo,
Carlos.

[jfgimenez]

Carlos,
> Y si, además, el que escribió el command tuvo la idea de usar la
> palabra Self como nombre de variable/parámetro, imposibilitando usar
> los comandos dentro de una clase sin que se generen conflictos, ni te
> cuento :P
No comments ;-)))
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info