INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

RTF Printing

RTF Printing

(OP)
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."hammer

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

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

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

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

RE: RTF Printing

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.



RE: RTF Printing

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

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

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: Word Automation - print and quit

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.

RE: RTF Printing

Use the selprint method of the OLE control.

CODE --> foxpro

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: How to get the best response from the forum first.

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

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 Smileing

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.

RE: RTF Printing

Quote:

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

RE: RTF Printing

Here:

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

Regards

Griff
Keep Smileing

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.

RE: RTF Printing

Scott
This is confusing you said

Quote (Scott)

I experimented with an RTF control on my form

Now you say;

Quote (Scott)

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: How to get the best response from the forum first.

RE: RTF Printing

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.

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

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.

RE: RTF Printing

(OP)
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."hammer

RE: RTF Printing

I'm oversimplifying, ok. Then you lost me, too.

I still have no idea what is the typical source of one report run. I would not expect that you turn all your data into one giant PDF. It may be oversimplifying things to say you only want to print one memo instead, but so what is the truth? If I assume you print multiple memos from multiple records, which means printing multiple documents, in the end.

Bye, Olaf.

RE: RTF Printing

(OP)
Hi Olaf,
Sorry for the confusion, let me try to paint a clearer picture.
So the first thing that happens is some data is collected for comparison across several tables, but essentially it's Utility Power capacity, Generator plant Capacity UPS total capacity, and Cooling Plant Capacity. In my world, these 4 things make up a "balance". Wherever the weakest one is, that's your maximum capacity.

Each of these areas has it's own database to go with it, and we spend a lot of time describing the various points or characteristics of the components that make up each part of this. We also cover other areas, like the make up of various "zones". These zones include things like data hall, outside plant, fiber tunnels, and other parts. We use 3 standards as well and each standard has a different set of audit criteria. So we have them setup in 4 parts: Requirement, Criteria, Result and Comments. There are over 200 items in the smallest one. These can become quite detailed. And in this case, we would want at least 2 of not all 4 of them to be RTF fields. The "Result" field is ok not to be, it has 7 possible options and they are fixed. And this is one component of the overall report. (This is the easiest of them as well, we have 2 different sets actually, but I want to combine this one into the report as an appendix in the future. Though I suppose that could be done by creating two PDF outputs, and then merging them later).

The other areas though are more complicated. And we may have a building that is multistory, (almost always actually), up to 15 - 20 floors. Each floor then has multiple zones, and each zone can be of a different type. So this all gets detailed. We're dealing with data centers, and they are highly complex systems, much like a highly complex application. Some are simpler than others, but it's the complex ones we deal most with.

Then we add in the analysis element, which we do utilizing CFD (Computational Fluid Dynamics), and we have those results as well. One thing about CFD is the image is one thing, but the analysis is similar to that of reading an x-ray. You have to understand what the data is telling you and we may have 8 - 20 different images that are associated with that. These in particular are conducive to lots of explanation and text, and another place where RTF would be of huge benefit in our reporting documents. Its set up so our analysts can drag and drop an image into a form, and then annotate that. But we also bring other metadata with that, like temperature, velocity, scale, and multiple views. There is no one "formula" in a CFD arrangement, we just have to keep adding images and annotations until we have a full analysis of what we've produced. We add some data that isn't reported as well, of course, which we use for longer term research and trending (even questions we don't know how to ask yet). So, when we compile the full analysis of any one site (which may also include an analysis of risks to the site), it's a big document. At the moment, some of it we do still by hand, as we're building this out, other pieces we are getting some traction on, but one thing I'm trying to do as well is think through the full requirement. I'm trying to prevent having to do major re-write later. I know this is a lot of detail, but I am hoping to create the picture for you of the problem we are trying to solve.

In fairness what we have seen so far is a major competitive advantage, because a) we don't reinvent the wheel every time we get asked to do an analysis (and we may get asked to analyze the same site by more than one client, sometimes from different perspectives, but we have the benefit then of just adding parts we don't already have detail for) and b) that means we can do the same type of analysis in about 1/2 the time as our competitors. We charge about 25% less, so it really is the holy grail of "Better, faster, cheaper", except for us "Cheaper" means we do far more in less time, and therefore we are actually charging more per hour, just completing the work in less time, which of course means higher margins. This field is highly competitive, and we are becoming unique in our approach to the consultancy. There is a whole project management component as well, which I haven't even begun to tackle, but once this core part is done, that will become the next focus, as I have spent an entire lifetime in "parallel" activity as a PM.

Sorry for the long winded explanation, but maybe it sheds some perspective on why this is important to me.


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

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

RE: RTF Printing

We're still only talking about the report, are we? I'll take a closer look tomorrow.

Bye, Olaf.

RE: RTF Printing

(OP)
Hi Mike,
Struggling with the French. Is there an English version? I checked the home page of the site, but didn't find one, and even Google Translate struggles with this.

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

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

RE: RTF Printing

Scott
No I wrote this for the french community, but the important part is this.

CODE --> foxpro

CLEAR ALL

CLOSE DATABASES all 
LOCAL lcStr  
lcstr = "Note that there is a limit of 32 characters total for the sum of text"+;
"before and text after for simple numbering. Multilevel numbering has a limit"+;
"of 64 characters total for the sum of all levels.NOTE: The file must have a"+;
       ".RTF extension to work properly." && Remplir la variable de texte.
CREATE cursor ctext (lctext m,gText g) 
INSERT INTO ctext (lctext) VALUES (lcStr) 
_rtfFile = "c:\"+SYS(3)+".rtf"  
SCAN 
          SET TEXTMERGE TO &_rtfFile NOSHOW
          SET TEXTMERGE ON
           \\{\rtf1 <<ALLT(cText.lcText)>>}
          SET TEXTMERGE TO
   APPEND GENERAL gText FROM &_rtfFile CLASS "RICHTEXT.RICHTEXTCTRL.1" &&Class RTF
ENDSCAN
REPORT FORM rtfdemo PREVIEW NOCONSOLE
ERASE &_rtfFile 

Mike Gagnon

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close