Need VFP9 commands to print in landscape without Report Forms 1

[amatureo]

Trying to add Ubuntu 18.04 workstations to a LAN of Win7 computers. My Visual Foxpro 9 compiled exe runs via wine on the Ubuntu installation. The VFP9 exe on Win7 can access and manipulate data on the Linux computer. The VFP9 exe on Linux can access and manipulate data on the Win7 computers. The exe on the Linux computer can print to Win7 computers except when Report Forms are used. Instead of printed lines, all Report Forms print as solid black boxes. I thought that it might be a font problem, but I've been unable to change to any font that prints properly. I've been trying to solve this problem for a few weeks now - no joy.

I decided to rewrite my printouts without Report Forms, and I've made some progress. The one sticking point is that I haven't figured out how to use a VFP command to change the orientation from Portrait to Landscape. It was simple in Report Forms, but I can't find the answer to hard code commands in my exe. Most printouts are in Portrait, but I need a solution to all for a few Landscape orientations. I can issue sys(1037) and manually change the setup, but I need a way to avoid the user interaction.

If anyone can steer me in the right direction I'd be eternally grateful.

 

[Mike Lewis]

Before you completely give up with VFP reports, check the Printer Envionment setting. Open your report in the report designer. Go to the Report menu, and check that there is no tick against the Printer Environment option. If there is a tick, clear it, then save the report.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

To answer your question about what commands to send to change the printer's orientation ....

The answer depends on the printer. In most cases, you would have to send a so-called escape sequence, that is, a series of codes preceded by ESC (ASCII 27). You would have to study your printer's documentation to find the actual sequence to send in each case.

An alternative approach would be to create a second printer driver, and to keep that permanently set to landscape. Copy the existing printer driver and give it a new name. Then go into that copy's properties and set it to landscape. (You do all this from the Windows control panel.) When you are ready to print a landscape report, use SET PRINTER TO to choose that printer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[tomk3]

Hello,

not what you have asked for, but maybe you can use free foxypreviewer, generate a PDF from a normal report (in landscape) , its just one line.
Then copy that pdf to printer or call a viewer with printcommand.

Reagrds
tom

With FP you will have MUCH better preview and save as xls,rtf,pdf in your application

http://www.foxypreviewer.com/

 

[amatureo]

To Mike Lewis: I actually have already tried the second printer technique. It works just fine on a Win7 workstation, but I've been unable to use it from a Linux workstation. For some reason I can't find the 2nd shared printer from the Linux computer. Win7 uses a standard TCP/IP for the original printer, and a WSD port for the second version of the same printer. I'm not a Linux expert, so maybe my understanding of CUPS printer management is the problem.

To tomk3: Your suggestion is also something I've considered. Again, I'm working with the Linux computer to see if I can create and print the pdf.

Thanks guys for responding. I'll keep plugging away to see if I can solve the problem. And Mike, I really would like to use my report forms, so I'll explore your first suggestion.

 

[amatureo]

To Mike: Just opened one of my Report Forms that doesn't print correctly and the Printer Environment option wasn't ticked.

 

[Mike Lewis]

Amatureo, going back to your original question, you say that your reports come out as solid black. That suggests a problem with the printer driver. Have you tried printing to a different printer? That would tell you if the fault lies on the VFP side or with the printer driver. If the latter, check with the printer manufacturer to see if there is an updated driver you could use.

If you don't have a second printer attached to your computer, try outputting to a PDF. Again, if that works, that would suggest the problem lies with the printer driver.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[amatureo]

Just printed a Report Form to a PDF and it has the same problem with all printed lines being solid black. So problem is VFP program.exe running via Wine on a Linux computer.

 

[amatureo]

If I don't use Report Forms, if I simply SET PRINT TO and "? output", it prints fine. The problem is that my program currently uses a slew of Report Forms, all which work perfectly on Win7 computers. I started the tedious process of converting them, but that's when I ran into the problem that some of them need to print in landscape, and I haven't found a universal way to have my VFP program set the orientation on the fly.

I've just been hoping that someone has solved this Report Form printing issue that exists when printing to a Win7 printer from Ubuntu 18.04.

 

[tomk3]

Hello,

1) can you make a small test report in font courier new and print it and generate a pdf ?
2) Can you install a "dummy printer" with driver "General" in windows and try to print on that ?

Regards
tom

 

[amatureo]

I've tried test reports with several different fonts, including courier new, and the PDF printout is a black box, not a printed line.

I've created a Virtual_PDF_Printer using a downloaded PPD driver file for Linux from the printer manufacturer (Brother) - still prints a black box.

I'm pretty discouraged because, other than Report Form printing, my VFP program runs great in a combined Win7 and Linux LAN.

Thanks for giving some of your time to try to solve this problem. It's a doozy.

 

[Mike Lewis]

Amatureo, if you would care to let us know the make and model of the target printer, I could probably find the codes you need to send to switch between landscape and portrait (although it would be a pity not to solve the underlying problem of the black boxes).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

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

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.)

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

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:

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

https://www.doschke.name

 

[Mike Lewis]

Olaf, if I've understood your suggestion correctly, you would need to remove the PACK from the code on the Windows side, since by definition printjobs.dbf would need to be open in shared mode. That's a minor point, of course, and does not affect the validity of your solution, which is definitely worth following up.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[amatureo]

Thanks Olaf. You've come up with a logical, great idea. It may not work for me in the long run though, because my goal is to provide an option to run my VFP program in LANs with only Linux computers. In that situation there would be no Windows computer to do the printing.

I haven't yet installed a printer on a Linux computer to see how Report Forms print locally, but my expectations aren't high. Printing to a local Linux PDF didn't work, so it's doubtful it would be any different to a printer.

And yes, Olaf, this likely means that the problem is CUPS. And what can I do about that? Suffer in silence or keep searching? Onward!

 

[amatureo]

Ooh La La. I may have found the solution!

I'll be testing further, but this looks like the issue. The default setting of REPORTBEHAVIOR 90 causes Report Forms to print black boxes. SET REPORTBEHAVIOR 80 allows for correct printing of a Report Form.

So many thanks for your time guys.

 

[Mike Lewis]

Please keep us informed. I can't imagine why it should be OK with REPORTBEHAVIOR 80 but not with 90, so if you get any further information, it would be good to know about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I think then it's related to gdiplus.

As reportbehavior 90 was introduced, it was noted all texts become a bit longer. Some report designs with report controls very tightly adjusted to the actual width of printed text started printing *****, the epxression you get to denote insufficient space for printing (instead of printing a clipped number that becomes a wrong magnitude, for example).

And that was then explained by the change of which GDI library VFP used.

When you say you run a VFP app on Linux, then I assume you're using a Windows emulator. I guess that lacks gdiplus functionality, then and has black boxes as fallback.

Mike, yes, you're right, when every client should be able to add to printjobs, PACK is a bad idea. In the long run, at some point you'd want to get rid of processed data. In the first place, you can simply drop that without replacement, of course. And instead run a pack function that tried to temporarily get explusive access for packing.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[amatureo]

So ... SET REPORTBEHAVIOR 80 allows for actual print instead of boxes, but I did have to add NOCONSOLE to REPORT FORM commands to prevent output echoing to the current screen.

One problem remains. Report forms set to print in Landscape are still not working.

I am thankful for the progress that has been made.

 

[tomk3]

Hello,

can you put the report files (frx,frt) external and hack them before using them for printout (field expression If I remember)

If using reportbehaviour 8 , does printing in landscape to a pdf printer work ?

Regards
tom