Duda al compilar la Clase TDirPrint
Posted:
Fri Jan 09, 2015 4:43 pm
by 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
Re: Duda al compilar la Clase TDirPrint
Posted:
Fri Jan 09, 2015 5:46 pm
by 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
Re: Duda al compilar la Clase TDirPrint
Posted:
Fri Jan 09, 2015 6:38 pm
by ruben Dario
carlos vargas wrote: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
Re: Duda al compilar la Clase TDirPrint
Posted:
Fri Jan 09, 2015 7:43 pm
by Antonio Linares
Salvo que me equivoque, yo diría que Harbour no soporta el comando SWICTH...
Re: Duda al compilar la Clase TDirPrint
Posted:
Fri Jan 09, 2015 8:25 pm
by ruben Dario
Antonio Linares wrote: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
Re: Duda al compilar la Clase TDirPrint
Posted:
Sat Jan 10, 2015 3:26 am
by 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.
Re: Duda al compilar la Clase TDirPrint
Posted:
Sat Jan 10, 2015 2:20 pm
by 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.)
Re: Duda al compilar la Clase TDirPrint
Posted:
Sat Jan 10, 2015 7:41 pm
by carlos vargas
busca en el foro por DETACHED variable
http://en.wikipedia.org/wiki/Harbour_%28software%29revisa: 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.