Duda al compilar la Clase TDirPrint

[ruben Dario]

Saludos al Foum

Cuado la compilo con xHarbou funciona bien, pero con Harbour da un error al compilar
El Error da el la linea DEFAULT

Code: Select all  Expand view

METHOD sendtoprinter( lDelete )
   LOCAL x     := 1
   LOCAL nRet  := 0
   LOCAL cMsg  := ""
   LOCAL lShow := .f.

   DEFAULT lDelete := .t.

   SET DEVICE TO SCREEN
   SET PRINTER TO

   IF ::nCopy < 1
      ::nCopy := 1
   ENDIF

   FOR x := 1 TO ::nCopy
      ::printlogo()

      nRet := PrintFileRaw( ::cPrinter, ::cFile, ::cDocument )

      cMsg += "Copy " + WCStr( x ) + CRLF

      IF nRet # 1
         lShow := .t.
      ENDIF

      SWITCH nRet
      CASE -1
         cMsg += "Invalid parameters passed to function" ; EXIT
      CASE -2
         cMsg += "WinAPI OpenPrinter() call failed"      ; EXIT
      CASE -3
         cMsg += "WinAPI StartDocPrinter() call failed"  ; EXIT
      CASE -4
         cMsg += "WinAPI StartPagePrinter() call failed" ; EXIT
      CASE -5
         cMsg += "WinAPI malloc() of memory failed"      ; EXIT
      CASE -6
         cMsg += "File " + ::cFile + " not found"        ; EXIT
      DEFAULT
         cMsg += "PRINTED OK!!!"
      END

      cMsg    += CRLF + CRLF

   NEXT

   IF lDelete
      FErase( ::cFile )
   ENDIF

   IF lShow
      MSGINFO( cMsg, ::cMsg )
   ENDIF

   RETURN NIL

 

[carlos vargas]

verifica que fivewin.ch este en la cabezera de este archivo prg, dado que ahi esta la definicion de esta instruccion, en caso de no querer usar esta instruccion reemplazar por

Code: Select all  Expand view

IF lDelete==NIL
 lDelete := .t.
ENDIF
 

[ruben Dario]

verifica que fivewin.ch este en la cabezera de este archivo prg, dado que ahi esta la definicion de esta instruccion, en caso de no querer usar esta instruccion reemplazar por

Code: Select all  Expand view

IF lDelete==NIL
 lDelete := .t.
ENDIF
 

Carlos Grac ias

el fivewin.ch si esta en la cabezera.
me refiero que en la compilacion con Harbour el error de compilacion da en la linea DEFAULT

CASE -6
cMsg += "File " + ::cFile + " not found" ; EXIT
DEFAULT
cMsg += "PRINTED OK!!!"
END

[Antonio Linares]

Salvo que me equivoque, yo diría que Harbour no soporta el comando SWICTH...

[ruben Dario]

Salvo que me equivoque, yo diría que Harbour no soporta el comando SWICTH...

Si Antonio parece que no lo soporta

Tambien el CASE de esta manera tampoco
CASE nLKey IN { K_ALT_W, K_CTRL_W }
o
if opr IN { 73, 5, 95, 96 } .and. op_xod IN { 5, 4 }

en xharbour si funciona

[carlos vargas]

ja, ja, me fije solo el el primer default del código que has puesto y he asumido que ahi era el error.

3. SWITCH / [ CASE / [EXIT] / ... ] OTHERWISE / END[SWITCH]
In Harbour it uses jump table with predefined values what gives
significant speed improvement in comparison to sequential PCODE
evaluation just like in DO CASE statements.
In xHarbour SWITCH does not use such jump table and generated
PCODE is similar to the one used for DO CASE or IF / ELSEIF
and only the main switch value calculation is optimized and
reused for all statements so speed improvement is relatively
small.
In xHarbour instead of OTHERWISE the DEFAULT clause is used.
As SWITCH values Harbour supports integer numbers and strings, f.e.:
switch x
case 1 ; [...]
case 10002 ; [...]
case "data" ; [...]
otherwise ; [...]
endswitch
xHarbour supports only integer numbers and one character length strings
like "A", "!", "x", " ", ...

entonce quedamos que switch es soportado por harbour, con una anotación: en xharbour se utiliza default y en harbour se usa otherwise como el el do case tradicional.

[carlos vargas]

###    IN, HAS, LIKE OPERATORS    ###
=====================================
xHarbour has three operators defined as identifier: IN, HAS, LIKE
IN is synonym of $ operator and it's translated by lexer to $.
It does not give any new functionality. For portable code use $.
HAS and LIKE are regular expressions operators. In Harbour they have
the same functionality as HB_REGEXHAS() and HB_REGEXLIKE() functions:
      <x> HAS <y>    => HB_REGEXHAS( <y>, <x> )
      <x> LIKE <y>   => HB_REGEXLIKE( <y>, <x> )

Using identifiers as operators is not compatible with Clipper preprocessor
precedence rules and introduces bugs to language syntax so Harbour will
never support it directly as operators. Using operators for regular
expression introduce yet another unpleasant thing. It forces linking
regular expression library with final application even if it does not
use RegEx at all. In Harbour RegEx library is optional and linked only
when user use one of HB_REGX*() functions or explicitly use REQUEST
command.

[ruben Dario]

Gracias Carlos.
Si lo que tu comentas, me habia dado cuenta y le hice el cambio.
Lo mismo con las otras ya le hicel el cambio

CASE nLKey IN { K_ALT_W, K_CTRL_W }
o
if opr IN { 73, 5, 95, 96 } .and. op_xod IN { 5, 4 }

Gracias por tu informacion.

Carlos
Tu sabes porque pasa esto y xHarbour Funciona Bien en Harbour CAPTION " &P " da el error Ahi parace que no acepta &P lo cambie por %PR y ahi gunciona
DIce Eror E0042 mcro es of declares simbol "&P" parece que es reservado.

@ 12, 20 GET lBtn1 PUSHBUTTON ;
CAPTION " &P " ;
COLOR cBtnClr ;
STATE {|| nBtn := IsPressed( 1 ) }

Para este Codigo pasa lo mismo los errores estan en esta linea
@ fil-15,col+clpun GET oV800_1:&prk PICTURE opiun WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)
@ fil-15,col+clpkl GET oV800_1:&prk PICTURE opikl WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)
@ fil-15,col+clpps GET oV800_1:&pre PICTURE opips WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)

Exactamente en oV800_1:&prk oV800_1:&prk oV800_1:&pre

**************************** ESTIMADOS
FUNCTION LSUMP(fil,col,met)
Local pre := "M_pesp"+met
Local ppr := "M_pre"+met
Local prc := "M_prec"+met
Local prk := "M_Kpre"+met
Local pru := "M_Upre"+met
Local prm := "M_Mpre"+met


//alert(str(fil,2,0)+" "+str(col,2,0) )
oV800_1:&pre := oV800_1:&ppr * oV800_1:&prc
if oV800_1:H_FAC="0"
oV800_1:&prk := oV800_1:&ppr
oV800_1:&pru := oV800_1:&ppr
else
oV800_1:&prk := oV800_1:&ppr * (oV800_1:KILMIL/1000)
oV800_1:&pru := oV800_1:&ppr
endif

@ fil-15,col+clpun GET oV800_1:&prk PICTURE opiun WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)
@ fil-15,col+clpkl GET oV800_1:&prk PICTURE opikl WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)
@ fil-15,col+clpps GET oV800_1:&pre PICTURE opips WHEN oV800_1:aContl[1]=5 COLOR colorset(C_FORMUL_FONDO)


return(.t.)

RETURN(.T.)

[carlos vargas]

busca en el foro por DETACHED variable
http://en.wikipedia.org/wiki/Harbour_%28software%29
revisa: Macro Operator (runtime compiler)
tambie lee:

### DETACHED LOCALS AND REFERENCES ###
============================================
When local variables are used in codeblocks then it's possible that
the codeblocks will exist after leaving the function when they were
created. It's potentially very serious problem which have to be resolved
to avoid internal VM structure corruption. In Clipper, Harbour and
xHarbour special mechanism is used in such situation. Local variables
are "detached" from VM stack so they are still accessible after leaving
the function, f.e.:
proc make_cb()
local n := 123
return {|| ++n }
We call such variables "detached locals".
Here there are two important differences between Clipper and [x]Harbour.
In Clipper variables are detached when function exits (returns) and it
does not know which variables were used but simply detach whole local
variable frame from VM stack. It's very important to know that because
it can be source of serious memory problems in OS like DOS.
This simple code illustrates it:

// link using RTLINK and run with //e:0 //swapk:0
// repeat test second time with additional non empty parameter <x>
#define N_LOOPS 15
#xcommand FREE MEMORY => ? 'free memory: ' + ;
AllTrim( Str( Memory( 104 ) ) )
proc main( x )
local n, a
a := array( N_LOOPS )
FREE MEMORY
for n := 1 to N_LOOPS
a[n] := f( x )
FREE MEMORY
next
return
func f(x)
local cb, tmp, ref
tmp := space( 60000 )
if empty( x )
cb := {|| .t. }
else
cb := {|| ref }
endif
return cb

If you execute above program with non empty parameter then 'tmp' variable
is detached with codeblock which uses 'ref' variable and not released as
long as codeblock is still accessible. It means that in few iterations
all memory are allocated and program crashes. Clipper's programmers should
know that and be careful when use detached local and if necessary clear
explicitly other local variables before returning from the function by
setting NIL to them.
In Harbour and xHarbour only variables explicitly used in codeblocks
are detached and detaching is done when codeblock is created and original
local variables are replaced by references. It is possible because Harbour
and xHarbour support multilevel references chains so it works correctly
also for local parameters passed be reference from parent functions.
In Clipper only one level references are supported what creates second
important differences. When Clipper detaches frame with local parameters
then it has to unreference all existing references breaking them. This code
illustrates it:

proc main()
local cb, n := 100
mk_block( @cb, @n )
? "after detaching:"
? eval( cb ), n
return
proc mk_block( cb, n )
n := 100
cb := {|| ++n }
? "before detaching:"
? eval( cb ), n
return

Above code compiled by Clipper shows:

before detaching:
101 101
after detaching:
102 101

so after detaching the references to 'n' variable is broken and codeblocks
access his own copy of this variables.
In Harbour it works correctly so the results are correct and it shows:

before detaching:
101 101
after detaching:
102 102

In xHarbour ( for unknown to me reasons ) Clipper bug is explicitly emulated
though it was possible to fix it because xHarbour inherited from Harbour
the same early detaching mechanism with multilevel references so just like
in Clipper xHarbour programmers have to carefully watch for possibly broken
references by detached locals and add workarounds for it if necessary.