RTF Printing

[Scott24x7]

I experimented with an RTF control on my form, and when I tried to print that data from the memo field in a report form, I just got "memo" in the field. Is there some way to print RTF data in the report form?

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Nigel Gomm]

see

http://www.tek-tips.com/viewthread.cfm?qid=1671613

hth

nigel

 

[Scott24x7]

Thanks Nigel. Bit disappointing. And the Moxy print option seems to be gone, as the link creates a 404 error.
Since there would be a number of RFT fields to print in my case, and much more than 1 page, it sounds like this is a no-go...


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

In the thread that Nigel referenced, I suggested creating a cursor containing a general field, then use APPEND GENERAL to get the RTF into that field, and then to print it via a report. I still think that's a good option. But if you have multiple RTF fields in each record, and if the total size of those fields in one record could exceed one page, then I agree that it won't work.

Another option would be to abandon doing it in a VFP report, and to use Word Automation instead. Remember, Word can natively read and write RTF files. So you could open the file in Word (via Automation), add whatever other data you need for the report, then print it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Hi Mike,
I have never worked with any of the Office Automation, but that doesn't mean I'm not willing to give it a dive in. I have an old Hacker's Guide to VFP 6.0 (I don't think they ever made one for the later versions), that has some stuff about office automation in it. Did it change much after that, or is that a good place to start?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott, if you've never worked with Automation before, it could be a big lump of information to swallow just in order to solve one problem. On the other hand, it is an extremely useful lump. It will open many other doors for you in the future.

The Hackers Guide would be a good place to start (especially the topic "It Was Automation, You Know"), but it will only take you so far. I'm sure you'll find plenty of tutorials on line if you look around (and maybe others here can recommend some specific places to look).

Version 6 of the Hackers Guide is not the latest. There is also a version 7. But there were no material changes as far as Automation is concerned. Tamar also wrote a book called "Microsoft Office Automation with Visual FoxPro" which will give you a lot more relevant information.

Good luck with this,

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

When you use the RTF control on your form, the most natural thing to do is using it on reports, too. And that happens, if you do what Mike suggests and make use of the Olebound control in reports and bind it to a general field you set to the RTF via first storing RichTextcontrol.TextRTF to a file and then APPEND GENERAL yourrtffield FROM thertffile "RICHTEXT.RICHTEXTCTRL.1".

Notice: Unlike APPEND BLANK, APPEND MEMO or APPEND GENERAL both work on the current record and don't append a new record, they only "append" a value into the field you specify. So a usual approah to fill a general field is using APPEND BLANK first to create a record in a cursor and then APPEND GENERAL.

Within the report, your oleboundcontrol's controlsource is that general field and that's it.

Bye, Olaf.

 

[Mike Lewis]

Olaf, I think the reason Scott didn't go down that road is that he has RTF fields that extend over a page boundary (is that right, Scott?). That would be a limitation on any approach that involves the VFP report writer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

That's correct Mike.
They are a problem there.
In our data center due diligence, these full reports may be 50 - 100 pages long, with lot of images, but the problem is with an RTF it has to compete for space with everything else on the page as well. Since the bigger value of our data is having it in accessible fields, so that we can also do some analytics and unstructured data comparison, the fields can be big. And we can't predict where they will break on a page.
From the sounds of things though, Word automation is really just the ticket, and then we can do more with it. So for now, we're stuck with standard text controls, but we'll replace them later with RTF again after we get the automation stuff sorted out.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Not sure whether that wouldn't be covered by the olebound control, too. Well, thesecondary approach is to store a rtf file and either automate Word. You dpon't need any boook and you only need shallow automation knowledge to start Word, open an RTF file and print it: thread184-445705

Just specify the RTF filename of the file you create from olecontrol.TextRTF or the memo you bound to the olecontrol of your form.

Bye, Olaf.

 

[Mike Gagnon]

Use the selprint method of the OLE control.

LOCAL lcPrinterName, lnPrinterHDC 
 DECLARE LONG CreateDC IN WIN32API STRING, STRING, LONG, LONG 
 DECLARE LONG DeleteDC IN WIN32API LONG 
 lcPrinterName = GETPRINTER() 
 IF NOT EMPTY(lcPrinterName) 
  * get a handle for the printer device 
  lnPrinterHDC = CreateDC("WINSPOOL", lcPrinterName,0,0) 
  thisform.olecontrol1.selprint (lnPrinterHDC) 
  * get rid of the handle 
  DeleteDC(lnPrinterHDC) 
 ENDIF

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Scott24x7]

Hi Mike,
That's an interesting notion. But would this result in writing all your reports as code (not averse to that, just want to know what I'm getting myself into). I have done HPGL report writing in FPD26 back around 1993, so the concept isn't entirely foreign. And while a touch messy, can be pretty powerful as well.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[GriffMG]

I have a 'thing' that prints RTFs from VFP.

I last used it in VFP6 for something, it is called RTFPrinter.VCX

http://www.tek-tips.com/viewthread.cfm?qid=208667

I am looking for the rtfprinter.zip file...


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

In our data center due diligence, these full reports may be 50 - 100 pages long, with lot of images, but the problem is with an RTF it has to compete for space with everything else on the page as well.

Clearly that's going to be a problem with any solution that involves a VFP report. With that in mind, Automation does seem the best solution. Nor do I think that Mike G's or Griff's solutions would be adequate in this case - interesting as they both are - as they would only print the RTF, not all the surrounding information (correct me if I am wrong about that).

One other possibility comes to mind. Create the entire document as a single RTF file. It would mean programmatically encoding all the supporting information (data fields from the tables, headers and footers, page numbers, etc.) as RTF strings, and merging in the existing RTF from your forms. You could then print the whole thing with a simple call to ShellExecute().

It would mean you would have to learn how to format strings as RTF, but I can't imagine that would be very difficult. It is probably just a matter of surrounding each bit of text with some control characters. You could do the whole thing in a memory variable, then write it out to a file using STRTOFILE(). Then ShellExecute() the file, passing "print" as the second parameter.

This is all off the top of my head. I can't say for sure it would work, but it might be worth looking into a bit further.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Here:

http://www.finedata.com/shdata/rtfprinter.zip

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Gagnon]

Scott
This is confusing you said

I experimented with an RTF control on my form

Now you say;

But would this result in writing all your reports as code

Which is it, form or report?


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Olaf Doschke]

No, nothing already mentioned goes not go into the direction of printing via code.

50-100 pages of RTF coming from (I assume) a memo as part of an FRX make no sense to me. If I were you I would only print a summary or cover page or document name and offer to print such whole RTF texts as themselves.

If that's the nature of your reports, then I doubt that nature of reports more than any technical possibilities or difficulties. What sense does it make to put such vast texts into a report? This is not sound, it's a crappy idea you want to realize, if you ask me. The report itself would become a very tiny part of it. That would be a bit like having a report about movies embedding the whole movies, which would not be printable, of course.

Let's look back:
1. I mentioned embedding olebound control to FRX, that would simply print the RTF text. I think it also covers page breaks if your RTF is merely running text. If you talk of RTF documents, not only containing some bold or such modifed text, but Mike may be right, that it even wouldn't cover that case and only would be good for small RTF portions to cover bold, italic etc. partial text.

2. Mike Gagnon mentioned the bult in print functionality of the RTF control, that prints just the RTF. You can't put that code into a FRX or interleave or integrate it with a resto of your FRX, this simply would print RTFs from within the form without needing to write out a RTF file first.

3. Griffs class as far as I understand it does about the same as Mike Gagnons.

Printing whole documents each themselves having a page layout, how should that blend in to a report at all? This sounds like creating a series of print jobs interleaving a cover page with the documents, so you should rethink your whole strategy. I would just do a cover page report and print one per record followed by a print job of the document. This is not the topic of one report embedding all you want to print. Get a grip on the reality of this, what you wan to do is a batchjobs of prints, what hinders you to go about it exactly that way? There is no reason whatsover this has to go into one single report. I don't see that.

I have worked with real advanced printers with multiple output trays. They handle concurrent printing of many print jobs from different clients. So just in case you want to avoid other print jobs coming between your long report, there are ways to avoid that in hardware, not software. And the simplest hardware solution does not even need such an advanced printer, you only need a local printer not shared.

Bye, Olaf.

 

[Scott24x7]

Mike,
In this case I was working with an RTF in the form, and wanted to use it in a report form. I was only commenting that in my past (about 20+ years ago), I had to write a report in FPD2.6 that used embedded HPGL calls directly to the printer to control the output. It had some complex "white spacing" algorithm that I had worked out so that people with thin resumes didn't look so thin by spreading out the gaps between lines. (This was a client requirement, COAS at Indiana University job placement for students). The only way to do it was to get gritty with HP laser language.
I would certainly prefer not to have to go to that length, but if doing it programmatically is the only way to go, then I will consider it. I don't fully grasp your code, but if as Olaf mentions it's only to print the content of the RTF memo, that wouldn't give me everything I need for the report.

Olaf,
I know it seems like a lot of data, but it's not quite as bad as it seems. There are multiple records with multiple memo fields (just plain text now, but I want to convert them to RFT if I can get it to work). These combine with other image data (photos) that get output to PDF (just print to PDF, instead of a printer). So these docs end up being usually around 50 pages. We used to use Word and Excel, but we can't utilize the data then, and we have to do a bunch of work for calculations and comparisons by hand then, and that's highly error prone. So our approach instead is to break down the data into groups i.e. Mechanical, Electrical, Architectural, Telecomm, and throw that at a report form which has, as you suggested already, a summary, but then provides detail bands for the rest. The text then is just plan text. It would be much better if we could use an RTF control, so the output has a more "Word Document" feel to it.
I know our requirement may sound crazy to you, but for us it's a huge competitive advantage in time and consistency. Now we'd like to make it prettier. (I think I mentioned before we're shifting more to "core functionality is done, now it's time to make it pretty" in the development cycle). Hope all that makes sense, and thanks for all the suggestions, I'm just now trying to weigh the RTF vs. Office Automation, vs. report writing in code, vs. what we have now. I barely sleep anymore, and I'm looking forward to getting this really battened down finally so I can return to a normal life, and maybe even have a holiday...

Hi Griff,
I just got the ZIP downloaded, so will take a look thanks.

On the plus side, it gives me options to think about, and my thanks to all.



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

So you only want to print one record, do you? And mainly the RTF, don't you? Well, then the olecontrols selprint() method is your solution, isn't it?

I assumed you had multiple records, say 100-1000 and each has a 50 pages RTF doc inside and you wanted to roll all this into one report. If you want to print a single memo, I wouldn't let that go through a report at all. You want to print a document. So save a document and you may even go as simple as use ShellExecute with Action being "print" instead of "open".

Even if I consider your memo now as simple runnning text, you rather have a document at hand, and reports are ment to turn data into documents with repeatred sections. If you already have a document, a text, you print it. There is no summing, no grouping, nothing that asks for a report, as far as you told us the outset.

If you want to get a good answer come with all details we need to know.

Bye, Olaf.

 

[Scott24x7]

Olaf,
You lost me. I have dozens if not hundreds of records for each category, they all have multiple memo fields (which I want to turn into RTF, just haven't yet because I don't have a good solution). You're massively oversimplifying what I said, and I'm not sure why.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."