Hi everybody,
I need to print the value of an memo field. For this purpose I generated a
report with just one detail row per page.
That works great as long the text in the memo field is not to long.
But some rows contain quite a lot of text, that does not fit on one page. So
the rest of the text is just cut off.
Is there a chance to display respectively print the whole of the memo field
value on two or even three pages, if necessary?

Thanks in advance for helping!
Heinz

From:	Todd Kreuter [dBVIPS]
Subject:	Re: Printing large memo fields
Date:	Wed, 08 Dec 2004 08:42:27 -0500

Heinz Kesting wrote:
>
> I need to print the value of an memo field. For this purpose I generated a
> report with just one detail row per page.
> That works great as long the text in the memo field is not to long.
> But some rows contain quite a lot of text, that does not fit on one page. So
> the rest of the text is just cut off.
> Is there a chance to display respectively print the whole of the memo field
> value on two or even three pages, if necessary?

Hello Heinz,

I tried this last night. I was getting only one line of the memo on the
second page. Is that what you are seeing?

--
Todd Kreuter [dBVIPS]

From:	Heinz Kesting
Subject:	Re: Printing large memo fields
Date:	Wed, 8 Dec 2004 19:24:06 +0100

Hi Todd

> > I need to print the value of an memo field. For this purpose I generated
a
> > report with just one detail row per page.
> > That works great as long the text in the memo field is not to long.
> > But some rows contain quite a lot of text, that does not fit on one
page. So
> > the rest of the text is just cut off.
> > Is there a chance to display respectively print the whole of the memo
field
> > value on two or even three pages, if necessary?
>
> Hello Heinz,
>
> I tried this last night. I was getting only one line of the memo on the
> second page. Is that what you are seeing?

No, I guess you mean something different. If you take, for example an
entryfield and design its area in a report shorter than the max. possible
entry length in the linked table, the rest of the value would be cut off as
well when the report is rendered. So I supposed it's the same with my
editor.
The editor covers almost three quarters of the area of the report page,
above it is some headline only. I intent to enable to the user to print out
help texts, and in most cases the help text (stored in a memo field) does
not exceed the space of the editor object.
If it does, naturally the rest of the text is cut off, as well as it would
be the case in the shorter entryfield I mentioned at the top. So my report
usually covers just one page, but it should have more pages, if the content
of the entryfield exceeds the space of the editor.
That's why I thought it was up to me to watch if the text is larger
than 1 page, and then react (onRender ? for example) in the report. Only
that
I have not the faintest idea what this reaction should look like ...

Thank you for your reply - I hope I could explain what I'm trying to do ...

Regards, Heinz

From:	Todd Kreuter [dBVIPS]
Subject:	Re: Printing large memo fields
Date:	Thu, 09 Dec 2004 08:07:02 -0500

Heinz Kesting wrote:
>
> The editor covers almost three quarters of the area of the report page,
> above it is some headline only. I intent to enable to the user to print out
> help texts, and in most cases the help text (stored in a memo field) does
> not exceed the space of the editor object.
> If it does, naturally the rest of the text is cut off, as well as it would
> be the case in the shorter entryfield I mentioned at the top. So my report
> usually covers just one page, but it should have more pages, if the content
> of the entryfield exceeds the space of the editor.
> That's why I thought it was up to me to watch if the text is larger
> than 1 page, and then react (onRender ? for example) in the report. Only
> that
> I have not the faintest idea what this reaction should look like ...

If you make the text control expandable, it should expand to print the
contents. Unfortunately, it appears that when its starts rendering to
the next page, it is only rendering one line rather than the remainder
of the memo (first page expands just fine).

--
Todd Kreuter [dBVIPS]

From:	Heinz Kesting
Subject:	Re: Printing large memo fields
Date:	Thu, 9 Dec 2004 19:41:55 +0100

Hi Todd

> If you make the text control expandable, it should expand to print the
> contents. Unfortunately, it appears that when its starts rendering to
> the next page, it is only rendering one line rather than the remainder
> of the memo (first page expands just fine).

So you were on the right track - and I didn't know the expandable property,
so I thought you were after something else ... because I had already built
the editor as large as possible without expecting that it can expand itself
on demand.
So I think there's no way to get it working this way. First I thought I
could do this printing with classical printjob commands, but since the text
has some formatting on it, these formatting commands like

etc. are
printed as well, what made me finally think of a report for it.
(See a thread named "printJob" in the dbase.programming group from
02.Dec..04)
It appeared too difficult to me to extract all formatting commands from the
text before printing ...
However, can you think of another solution for this? Actually, I didn't need
a report for it, I just want to enable to hardcopy a helptext.

Thanks for your reply and help!
Regards, Heinz

From:	Todd Kreuter [dBVIPS]
Subject:	Re: Printing large memo fields
Date:	Thu, 09 Dec 2004 15:01:05 -0500

Heinz Kesting wrote:
>
> However, can you think of another solution for this? Actually, I didn't need
> a report for it, I just want to enable to hardcopy a helptext.

Hello Heinz,

Are you printing one memo at a time? Could you break up the memo based
on some average characters per line * lines per page, say 60 * 30.
Likely you would need a temporary table to put the pieces into a
separate row.

Just a thought.

--
Todd Kreuter [dBVIPS]

From:	Heinz Kesting
Subject:	Re: Printing large memo fields
Date:	Thu, 9 Dec 2004 23:12:48 +0100

Hi Todd

> Are you printing one memo at a time? Could you break up the memo based
> on some average characters per line * lines per page, say 60 * 30.
> Likely you would need a temporary table to put the pieces into a
> separate row.
>
> Just a thought.
And not a bad one, I think. Yes, I just want to print only one memo at a
time. The general idea is a small help system form - with a tree view object
on the left side with the available help topics, on the right side an editor
object datalinked to our memo field. The OnChange event of the TreeView
object finds via FINDKEY() the corresponding row and thus the help text is
displayed in the editor.
Once the editor holds text within, I thought the user would want to able to
print a hardcopy of his well-earned outcome :-), so only one memo could be
printed. I don't intent to let all memos printed, the print button makes it
clear to the user, saying "Print this topic".
If I get your idea right, you mean to calculate the amount of text that
would fit into one editor at a time. If then the current memo holds more
than the max. amount of text for the editor, it should be cracked up into
pieces each small enough to be printed on one page, storing them in a temp
table. That sounds pretty good - I'm gonna give it a try!

Thanks for this enlightenment!
Best regards, Heinz

From:	Geoff Wass
Subject:	Re: Printing large memo fields
Date:	Thu, 16 Dec 2004 13:23:33 -0500

Heinz Kesting wrote:
> Hi Todd
>
>> Are you printing one memo at a time? Could you break up the memo
>> based on some average characters per line * lines per page, say 60 *
>> 30. Likely you would need a temporary table to put the pieces into a
>> separate row.
>>
>> Just a thought.
> And not a bad one, I think. Yes, I just want to print only one memo
> at a time. The general idea is a small help system form - with a tree
> view object on the left side with the available help topics, on the
> right side an editor object datalinked to our memo field. The
> OnChange event of the TreeView object finds via FINDKEY() the
> corresponding row and thus the help text is displayed in the editor.
> Once the editor holds text within, I thought the user would want to
> able to print a hardcopy of his well-earned outcome :-), so only one
> memo could be printed. I don't intent to let all memos printed, the
> print button makes it clear to the user, saying "Print this topic".
> If I get your idea right, you mean to calculate the amount of text
> that would fit into one editor at a time. If then the current memo
> holds more than the max. amount of text for the editor, it should be
> cracked up into pieces each small enough to be printed on one page,
> storing them in a temp table. That sounds pretty good - I'm gonna
> give it a try!
>
> Thanks for this enlightenment!
> Best regards, Heinz

Heinz,

Another untested idea: when the user clicks your PRINT button, transfer the
content of the memo field to a file, open the file via OLEAutomation with a
browser (Internet Explorer) and use that to print the help text. You might
even be able to keep IE invisible so the user won't know how you are doing
the printing.

--

:-)

----------
Geoff Wass (dBVIPS)
Montréal, Québec, Canada

==========
=======
====
=
More dBASE information at http://geocities.com/geoff_wass

Please reply in the news groups only.
Have you backed up your work?!
=
====
=======
==========

From:	Heinz Kesting
Subject:	Re: Printing large memo fields
Date:	Fri, 24 Dec 2004 21:39:09 +0100

Hi Geoff,

> Another untested idea: when the user clicks your PRINT button, transfer
the
> content of the memo field to a file, open the file via OLEAutomation with
a
> browser (Internet Explorer) and use that to print the help text. You might
> even be able to keep IE invisible so the user won't know how you are doing
> the printing.

Sorry, I discovered your answer only today, I simply had not expected
another reply ...
Your proposal sounded nice, but wouldn't it print these ...

?
On the other hand, I have no idea how to handle it via OLEAutomation ...
Could you provide a small sample to help me on the track?

Merry Christmas, by the way ...

Best Regards, Heinz

From:	Geoff Wass
Subject:	Re: Printing large memo fields
Date:	Wed, 29 Dec 2004 13:13:29 -0500

Heinz Kesting wrote:
> Hi Geoff,
>
>> Another untested idea: when the user clicks your PRINT button,
>> transfer the content of the memo field to a file, open the file via
>> OLEAutomation with a browser (Internet Explorer) and use that to
>> print the help text. You might even be able to keep IE invisible so
>> the user won't know how you are doing the printing.
>
> Sorry, I discovered your answer only today, I simply had not expected
> another reply ...
> Your proposal sounded nice, but wouldn't it print these ...

?
> On the other hand, I have no idea how to handle it via OLEAutomation
> ... Could you provide a small sample to help me on the track?
>
> Merry Christmas, by the way ...
>
> Best Regards, Heinz

Heinz,

A belated Merry Christmas and Happy New Year to you (and everyone else).

To answer you question, no I think the HTML tags like

will be
treated like HTML, especially if you copy them to a someFileName.htm (or
someFileName.html). To learn about OLE Automation there are some articles by
Gary White which you can find in the KnowledgeBase or at my site in the
"Gary White" section under 32-bit Stuff (if I recall correctly). His
articles are for Word and Excel, but the technique would be the same for IE.

--

:-)

----------
Geoff Wass (dBVIPS)
Montréal, Québec, Canada

==========
=======
====
=
More dBASE information at http://geocities.com/geoff_wass

Please reply in the news groups only.
Have you backed up your work?!
=
====
=======
==========

From:	Heinz Kesting
Subject:	Re: Printing large memo fields
Date:	Wed, 29 Dec 2004 22:57:38 +0100

Hi Geoff,
>
> To answer you question, no I think the HTML tags like

will be
> treated like HTML, especially if you copy them to a someFileName.htm (or
> someFileName.html). To learn about OLE Automation there are some articles
by
> Gary White which you can find in the KnowledgeBase or at my site in the
> "Gary White" section under 32-bit Stuff (if I recall correctly). His
> articles are for Word and Excel, but the technique would be the same for
IE.
>
Only the other day I happened to meet with my original aim in this issue.
Unfortunately I can't tell what was wrong with my first attempts of report
with this, but now it works as desired. As Todd Kreuter as well seemed to
have problems with printing more than one page from a single memo he thought
of breaking the memo into pieces if there is more text contained than one
page could hold. While playing with it to find out the max. amount of text
for one page it happened that the temporary rowset I had created contained
still too much text for one page and was although printed correctly on the
next page, so I changed back to the original rowset and got it working. As
already metioned, I can't name the reason why it did stop printing in the
first attempt, too many try/error loops had taken place ...

If there is any interest in the code, then please reply here and it will be
posted in dbase.binaries, if that's the right place.

So for the time being I can save myself from struggling with OleAutomation
....
There's another report I'm currently working on which is causing trouble,
I'm afraid there will be a new thread about it, soon ...

Thank you a lot, anyway
Best regards, Heinz

From:	Geoff Wass
Subject:	Re: Printing large memo fields
Date:	Thu, 30 Dec 2004 13:09:22 -0500

Heinz Kesting wrote:
> Hi Geoff,
>>
>> To answer you question, no I think the HTML tags like

will be
>> treated like HTML, especially if you copy them to a someFileName.htm
>> (or someFileName.html). To learn about OLE Automation there are some
>> articles by Gary White which you can find in the KnowledgeBase or at
>> my site in the "Gary White" section under 32-bit Stuff (if I recall
>> correctly). His articles are for Word and Excel, but the technique
>> would be the same for IE.
>>
> Only the other day I happened to meet with my original aim in this
> issue. Unfortunately I can't tell what was wrong with my first
> attempts of report with this, but now it works as desired. As Todd
> Kreuter as well seemed to have problems with printing more than one
> page from a single memo he thought of breaking the memo into pieces
> if there is more text contained than one page could hold. While
> playing with it to find out the max. amount of text for one page it
> happened that the temporary rowset I had created contained still too
> much text for one page and was although printed correctly on the next
> page, so I changed back to the original rowset and got it working. As
> already metioned, I can't name the reason why it did stop printing in
> the first attempt, too many try/error loops had taken place ...
>
> If there is any interest in the code, then please reply here and it
> will be posted in dbase.binaries, if that's the right place.
>
> So for the time being I can save myself from struggling with
> OleAutomation ...
> There's another report I'm currently working on which is causing
> trouble, I'm afraid there will be a new thread about it, soon ...
>
> Thank you a lot, anyway
> Best regards, Heinz

Heinz,

That is indeed strange and, I'm sure, frustrating, but it is good you got it
working. If you have other issues, feel free to start a new thread. That's
never a problem!

--

:-)

----------
Geoff Wass (dBVIPS)
Montréal, Québec, Canada

==========
=======
====
=
More dBASE information at http://geocities.com/geoff_wass

Please reply in the news groups only.
Have you backed up your work?!
=
====
=======
==========