Newsgroup: it.comp.lang.vo-clipper
Titolo: [VO2] DataFiles in Crystal Report

Ciao a tutti,
vediamo se qualcuno di voi usa Crystal Report 4.6 e puņ aiutarmi...
In un .RPT uso un dbf di nome PIPPO.
Ho bisogno di cambiare il nome del dbf usato dal .RPT da PIPPO a TEMP,
perchč succede che se provo a ZAPpare PIPPO da VO non viene cancellato
nulla; evidentemente CR blocca exclusive il dbf.
Ho provato con l'assign di CR DataFiles, che nell'help di CR viene
descritto usabile con (da VB ovviamente):
	Form1.CrystalRep1.DataFiles(0) = "c:\apa\temp.dbf"
Il prototipo nella classe generata da VO č:
	ASSIGN DataFiles(index,;		// AS SHORT
	        	 uParam002,;		// AS STRING
			 ) CLASS CrystalReport
	// An array of database files to use when printing the report
In VO ho provato:
	oDCOleControl1:DataFiles[0] := "c:\apa\temp.dbf"
	oDCOleControl1:DataFiles[1] := "c:\apa\temp.dbf"
	oDCOleControl1:DataFiles    := "c:\apa\temp.dbf"
	oDCOleControl1:DataFiles    := {0,"c:\apa\temp.dbf"}
	oDCOleControl1:DataFiles    := {1,"c:\apa\temp.dbf"}
	oDCOleControl1:DataFiles    := {{0,"c:\apa\temp.dbf"}}
eccetera...
Qualcuno sa dirmi, gentilmente, come diavolo si gestisce questo
DataFiles ?
Grazie in anticipo,
	Francesco
-- 
"Uomo, tu sei giovane come la tua speranza e vecchio come la tua
angoscia"
"Man you are young like your hope and old like your anguish"

Ciao Francesco,
Io ho la versione 6.0 e per cambiare il
percorso del file uso la funzione:
PESetNthTableLocation(...)
xò non so se nella versione 4.6 era già implementata.
Se si prova a dare un occhio alla guida del
programmatore oppure al massimo richiedi un altro aiuto.
Ciao.

	oDCOleControl1:DataFiles    := {{0,"c:\apa\temp.dbf"}}
La definizione giusta č..............
	oDCOleControl1:[DataFiles, 0] 	:= "..."
aveva fatto impazzire anche me :-|||||
Saluti,
Antonello.

neanche usando le istanze che ci sono in Window:Init().
Io ho risolto utilizzando un collegamento ODBC ai DBF invece del
collegamento diretto, la cosa non mi piace + di tanto, perň funge.
Inoltre se dall'editor di CR, apri il tuo report, lo richiudi,
modifichi la struttura del DBF, riapri il report e fai la verifica del
database, CR ti dice che č aggiornato !!!!
Se poi chiudi CR apri il report e fai la verifica, si accorge delle
differenze nella struttura.
A questo punto temo si possa parlare di *BUG* :-((((((((
.....SPERO DI VENIRE SMENTITO.....
Antonello.

Ciao Alan,
mi sembra di averla vista da qualche parte, ma con tutte le ricerche che
ho fatto su Internet ho la testa un pò in pallone... comunque ci guardo
subito.
Approfitto per un'altra domanda su CR:
ho notato che dopo la prima stampa non posso più ZAPpare il dbf che usa
CR, pur avendo chiuso la finestra del report. Esiste qualche maniera per
sbloccare il dbf? Che so, sospendendo l'Ole o qualcosa di simile? Ho
provato con Ole:Destroy(), ma poi non riesco a farlo resuscitare,
neanche usando le istanze che ci sono in Window:Init().
Ti ringrazio,
	Francesco

-- 



A me questo problema non si presenta, io xò
mi interfaccio con CRW tramite una mia DLL
fatta in C per mia comodità e non utilizzo l'OLE.
Quello che faccio è in sostanza:
1. Aprire il REPORT (Job)
    PEOpenPrintJob()
2. Aggiornare tutti gli archivi utilizzati
    PEGetNTables()
    PEGetNthTableLocation()
    PESetNthTableLocation()
3. Aggiornare i subreports
    PEGetNSections()
    PEGetSectionCode()
    PEGetNSubreportsInSection()
    PEGetSubreportInfo()
    PEOpenSubreport()
    PEGetNTables()
    PEGetNthTableLocation()
    PESetNthTableLocation()
4. Richiamare le funzione per il settaggio
    di formule, filtri vari e ordinamenti
    PESetFormula()
    PESetSelectionFormula()
    PESetNthSortField()
5. Settare le opzioni di stampa
    PEGetPrintOptions()
    PESetPrintOptions()
6. Stampare su dispositivo Video/Stampante/File
7. Chiudere il Job del punto 1
    if PEIsPrintJobFinished( pJob )
        PEClosePrintJob( pJob )
    else
        {
        ...
        ...
        // se voglio annullare
        PECancelPrintJob( pJob )
        PEClosePrintJob( pJob )
        }
Dopodichè riesco a fare tutte le operazioni che voglio
sulle tabelle che utilizzava CRW.
Per comodità nell'applicativo VO faccio:
1. Quando parte
PEOpenEngine()
1. quando termina
PECloseEngine()
Prototipi per VO
_DLL FUNCTION PEOpenEngine() AS LOGIC PASCAL:CRPE32.PEOpenEngine
_DLL FUNCTION PECloseEngine() AS VOID PASCAL:CRPE32.PECloseEngine
Questo perchè se lo fai ad ogni stampa dopo circa 50/52 stampe
ti genera un errore irreversibile.
Se qualcosa non ti è chiaro ti posso mandare
quache pezzo dei miei sorgenti fatti in C.
Ciao.

 collegamento diretto, la cosa non mi piace + di tanto, però funge.


Ciao Alan,
quello che proponi mi sembra molto interessante, ma da studiare e
digerire un pò. Nel frattempo, causa urgenza, consegnerò l'applicazione
con le stampe fatte con RichEdit (orrore...) altrimenti mi fucilano.
Con i tuoi prototipi in VO, ed anche con uno mio fatto per DataFiles
(_DLL FUNCTION CDbf( cDbf AS STRING ) AS LOGIC
PASCAL:CRPE32.PESetNthTableLocation), reagisce bene, il fatto è che non
mi cambia il DBF! 
Mah! vedremo...
Grazie a tutti quelli che mi hanno risposto,
	Francesco


Ciao Francesco,
se ho letto bene hai definito nel seguente modo la funzione:
_DLL FUNCTION CDbf( cDbf AS STRING ) AS LOGIC
PASCAL:CRPE32.PESetNthTableLocation
Attento, il motivo per cui non reagisce potrebbe essere che la definizione
corretta è:
_DLL FUNCTION PESetNthTableLocation( printJob AS SHORT, tableN AS SHORT,
PETableLocation AS PTR ) AS LOGIC PASCAL CRPE32.PESetNthTableLocation.
Dalla guida dello sviluppatore di CRW:
BOOL CRPE_API PESetNthTableLocation (
 short printJob,
 short tableN,
 struct PETableLocation FAR *location
);
Parameter Description
printJob      Specifies the handle of the print job for which you want to
set a table's location.
tableN        Specifies the number of the table for which you want to set a
new location.
location      Specifies the pointer to PETableLocation.
Non penso che questa funzione in CRW 4.x aveva meno parametri di quelli che
ho nella 6.0?!?
Ciao e alla prossima.