Am I misunderstanding you or does the PDF print prove the problem is with CUPS and Linux/Windows in general and not VFP?
You said
amatureo said:
The EXE on the Linux computer can print to Win7 computers except when Report Forms are used.
So printing text is possible, you use a printer in generic/text only mode when you SET PRINTER TO and use \\ or ??? to print something, but is that really desirable?
If you can't get printing from Linux with CUPS to work, how about installing a VFP executable doing the printing and sending over data and what report to print with it? Some kind of printer spooler?
Central part may be a printjob DBF on the Windows client, simply printjob (report M, printing L default .f., printed L default .f.)
Code:
Use printjobs
Do While .T.
Scan For Not printed And Not printing
Replace printing With .T.
Report Form (printjobs.Report) To Printer
Replace printed With .T.
Endscan
Delete For printed
Pack
DoEvents
Enddo
The Linux side then adds print jobs via
Code:
INSERT INTO \\win7\data\printjobs.dbf (report) values ("myreport.frx")
Reports might be compiled into that print spooler EXE or could be separate files, they could even be on the Linux machine in a share the Win7 client can see. So Linux even keeps the data and only sends over a record for the job to be done.
There's more to add, like I already said the data to print also has to get there somewhere. It seems to me, that the Win7 client is the database server? Or is it rather the Linux computer serving data to multiple Win7 clients? That would make me wonder in which situation the server prints on clients, but whatever reason that may have.
The data the reports need could be in further DBF files you ZAP and populate with report data before queuing the print job. You could have many copies, eg even copy over the FRX including all data for the win7 client to run, so they become temporary frx including dbfs that could be erased after printing, a print queue with folders containing FRX and DBFs.
It's just making use of what already works. That's much less work than redoing reports without FRX, isn't it?
It really doesn't take much work to do some EXE repeatedly looking for some jobs to be done in a table defining them, it's really just a small scan loop. The only records that would remain are from reports somehow not finishing to print and causing this EXE to shutdown. Then you have records with printing=.T. and printed=.F. and those would be reports to repeat. What you'd also need is to ensure this is restarted when it doesn't run, so either turn it to a service or simply make yet another watch dog ensuring there is a vfpprintspool process:
Code:
cProcessToWatch = "notepad"
Do While .T.
lProcessRuns = ProcessRuns(cProcessToWatch)
If Not lProcessRuns
Run /N &cProcessToWatch
Endif
* prevent multiple processes by waiting the RUN effectively added ProcessToWatch to the Win32_process instances
Do While Not lProcessRuns
lProcessRuns = ProcessRuns(cProcessToWatch)
Enddo
Enddo
Function ProcessRuns()
Lparameters tcProcessToWatch
Local llProcessRuns, loWMI, loInstances
oWMI = Getobject("winmgmts:")
oInstances = oWMI.InstancesOf("Win32_process")
For Each oProcess In oInstances
If Lower(oProcess.Name) == Lower(Forceext(tcProcessToWatch,"exe"))
llProcessRuns = .T.
Endif
Endfor
Doevents
Return llProcessRuns
EndProc
This does so with notepad. If you run this and no notepad process is started, it starts notepad. when you close notepad, it is restarted.
How to ensure
this never shuts down? Well, it only runs another process and checks it, there's no unstability like FRX corruptions or missing data or any error in a report code or data related, that would hang this. But of course, having a service would add a bit more stability. It's just also a beast of another level, as VFP executables in themselves are not suitable as windows service, so you establish a service vis some tool eg look at faq184-6355. There are some things a service might not see: Mapped drives, so you need to work with UNC paths, also find the right system or domain account running SrvAny (as described in the FAQ) to be able to have the necessary permissions to see the file shares involved, if any, etc. So perhaps try the simple endless loop route first without deep diving into establishing a real Service on Win7. Another option to ensure some EXE runs is creating a task in the task scheduler running every minute and only restarting if the process hasn't yet finished. Such a task scheduler job would need up to a minute to detect the process crashed, that's the only disadvantage with that construct, but you can be sure that Windows takes care of the task scheduler to be running.
Bye, Olaf.
Olaf Doschke Software Engineering
