Access 2007 Rich Text Deficiencies?

[Neil]

I posted a few days ago that it seems to me that the Access 2007 rich text
feature does not support: a) full text justification; b) programmatic
manipulation.

I was hoping that someone might know one way or the other whether that was
true or not, or could point me to an article or help text that would. What I
have seen so far online and in Access 2007 help seems to confirm the above.
But that (or at least (b)) seems incredible that it would be so.

I need to make a decision regarding implementing rich text features, and I
need to decide whether to go with Access 2007 or use a third-party control.
The answer to the above will determine my decision.

Thus, if anyone has any information re. the above, or could point me to an
article that does, it would be greatly appreciated. So far, I have not been
able to find anything.

Thank you!

Neil

[John Mishefske]

Neil wrote:

I posted a few days ago that it seems to me that the Access 2007 rich text
feature does not support: a) full text justification; b) programmatic
manipulation.

I was hoping that someone might know one way or the other whether that was
true or not, or could point me to an article or help text that would. What I
have seen so far online and in Access 2007 help seems to confirm the above.
But that (or at least (b)) seems incredible that it would be so.

I need to make a decision regarding implementing rich text features, and I
need to decide whether to go with Access 2007 or use a third-party control.
The answer to the above will determine my decision.

I saw this nice compilation of issues with A2007 from Allen Browne:

http://allenbrowne.com/Access2007.html

--
'--------------------------
' John Mishefske
' UtterAccess Editor
' 2007 Microsoft Access MVP
'--------------------------

[Neil]

Thanks, John. Yes, I checked Allen's list. It's a great resource. I actually
sent him a note about these two deficiencies, to see if he wanted to add
them to his list, but I haven't seen anything there or heard back from him.

Neil

"John Mishefske" <jm**********@SPAMyahoo.comwrote in message
news:46***********************@roadrunner.com...

Neil wrote:

>I posted a few days ago that it seems to me that the Access 2007 rich
text feature does not support: a) full text justification; b)
programmatic manipulation.

I was hoping that someone might know one way or the other whether that
was true or not, or could point me to an article or help text that would.
What I have seen so far online and in Access 2007 help seems to confirm
the above. But that (or at least (b)) seems incredible that it would be
so.

I need to make a decision regarding implementing rich text features, and
I need to decide whether to go with Access 2007 or use a third-party
control. The answer to the above will determine my decision.

I saw this nice compilation of issues with A2007 from Allen Browne:

http://allenbrowne.com/Access2007.html

--
'--------------------------
' John Mishefske
' UtterAccess Editor
' 2007 Microsoft Access MVP
'--------------------------

[Allen Browne]

Neil, I don't understand your comment about not being able to assign values
programmatically.

Presumably you have a text box bound to a Memo field where the Rich Text is
set, or an unbound text box or text box bound to an expression, and the Rich
Text property is set. If that's the case, you should be able to set the
Control Source to something like:
="This has a <b>bold</dword."

Likewise, you can paste in text containing bulleted lists etc.

In HTML, you can justify a paragraph of text like this:
<p align="justify">
I guess you are saying that the A2007 rich text box does not render that
correctly.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Neil" <no****@nospam.netwrote in message
news:GF*******************@newssvr23.news.prodigy. net...

Thanks, John. Yes, I checked Allen's list. It's a great resource. I
actually sent him a note about these two deficiencies, to see if he wanted
to add them to his list, but I haven't seen anything there or heard back
from him.

Neil

"John Mishefske" <jm**********@SPAMyahoo.comwrote in message
news:46***********************@roadrunner.com...

>Neil wrote:

>>I posted a few days ago that it seems to me that the Access 2007 rich
text feature does not support: a) full text justification; b)
programmatic manipulation.

I was hoping that someone might know one way or the other whether that
was true or not, or could point me to an article or help text that
would. What I have seen so far online and in Access 2007 help seems to
confirm the above. But that (or at least (b)) seems incredible that it
would be so.

I need to make a decision regarding implementing rich text features, and
I need to decide whether to go with Access 2007 or use a third-party
control. The answer to the above will determine my decision.

I saw this nice compilation of issues with A2007 from Allen Browne:

http://allenbrowne.com/Access2007.html

--
'--------------------------
' John Mishefske
' UtterAccess Editor
' 2007 Microsoft Access MVP
'--------------------------

[Neil]

Yes, I suppose one can add the HTML codes manually, which works fine for
simple things like bolding, but would get a little dicier with complex
formatting.

But what I meant was that in RTF controls (such as the Microsoft Rich
Textbox control, or third-party controls, such as FMS's), you can change the
format of the text programmatically using methods built into the control.
For example, to set the below bold text, one would use the SelBold method in
conjuction with SelStart and SelLength. Again, with simple examples it
shouldn't matter; but with complex formatting it makes a big difference to
let the control set the RTF or HTML code for you.

So, it's those methods that appear to be missing from controls designated as
"rich text" in Access 2007. Having to set the HTML manually would be huge
deficit, especially since rich text controls that have been available for
many years (and are still available) provide the methods to do it
automatically.

Neil

"Allen Browne" <Al*********@SeeSig.Invalidwrote in message
news:46***********************@per-qv1-newsreader-01.iinet.net.au...

Neil, I don't understand your comment about not being able to assign
values programmatically.

Presumably you have a text box bound to a Memo field where the Rich Text
is set, or an unbound text box or text box bound to an expression, and the
Rich Text property is set. If that's the case, you should be able to set
the Control Source to something like:
="This has a <b>bold</dword."

Likewise, you can paste in text containing bulleted lists etc.

In HTML, you can justify a paragraph of text like this:
<p align="justify">
I guess you are saying that the A2007 rich text box does not render that
correctly.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Neil" <no****@nospam.netwrote in message
news:GF*******************@newssvr23.news.prodigy. net...

>Thanks, John. Yes, I checked Allen's list. It's a great resource. I
actually sent him a note about these two deficiencies, to see if he
wanted to add them to his list, but I haven't seen anything there or
heard back from him.

Neil

"John Mishefske" <jm**********@SPAMyahoo.comwrote in message
news:46***********************@roadrunner.com.. .

>>Neil wrote:
I posted a few days ago that it seems to me that the Access 2007 rich
text feature does not support: a) full text justification; b)
programmatic manipulation.

I was hoping that someone might know one way or the other whether that
was true or not, or could point me to an article or help text that
would. What I have seen so far online and in Access 2007 help seems to
confirm the above. But that (or at least (b)) seems incredible that it
would be so.

I need to make a decision regarding implementing rich text features,
and I need to decide whether to go with Access 2007 or use a
third-party control. The answer to the above will determine my
decision.

I saw this nice compilation of issues with A2007 from Allen Browne:

http://allenbrowne.com/Access2007.html

--
'--------------------------
' John Mishefske
' UtterAccess Editor
' 2007 Microsoft Access MVP
'--------------------------

[Allen Browne]

Okay: I'm not sure I see this as a huge deficit. Easy enough to knock up a
couple of functions to add the <band </bat SelStart and SelEnd etc if
you need that.

PlainText() is built in for going the other direction.

Perhaps it would be fair to say that the new HTML "rich text" is not mature
yet. Issues such as the way the spell-checker messes up the field bother me
more.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Neil" <no****@nospam.netwrote in message
news:nL****************@newssvr22.news.prodigy.net ...

Yes, I suppose one can add the HTML codes manually, which works fine for
simple things like bolding, but would get a little dicier with complex
formatting.

But what I meant was that in RTF controls (such as the Microsoft Rich
Textbox control, or third-party controls, such as FMS's), you can change
the format of the text programmatically using methods built into the
control. For example, to set the below bold text, one would use the
SelBold method in conjuction with SelStart and SelLength. Again, with
simple examples it shouldn't matter; but with complex formatting it makes
a big difference to let the control set the RTF or HTML code for you.

So, it's those methods that appear to be missing from controls designated
as "rich text" in Access 2007. Having to set the HTML manually would be
huge deficit, especially since rich text controls that have been available
for many years (and are still available) provide the methods to do it
automatically.

Neil

[Neil]

Yes, I can see that. Let me say a couple of things (not that you have a
choice in the matter... ;-) ).

1) I think some of the more complex features, like bulleting, paragraph
spacing, etc., might be a little trickier -- but maybe not. Suffice it to
say that anyone going to a "rich text" control would expect a more
programmatic interface, and not to have to manually apply code.

2) With that in mind, and since your page is about upgrading to Access 2007,
someone who's currently using a rich textbox control (such as the Microsoft
one), and is thinking about upgrading to A07 to take advantage of the
built-in rich text capabilities, should know about the lack of methods
available for applying rich text. To "upgrade" to the A07 rich text control
would actually be a "downgrade" if they are used to (and have code written
for) built-in methods for their current control. Thus, it seems that that's
a significant issue for someone considering porting their app to A07.

3) In my application (currently using the MS Rich Textbox control) I need to
concatenate several RTF strings into a single file. Being a newbie at rich
textbox controls, I was unable to do it, until Stephen Lebans graciously
helped me out by pointing out the SelRTF and SelText methods of the Rich
Textbox control, which allow me to append one control's formatted text into
another. Without those methods, I'd have to work within the RTF code to
determine how to concatenate the two strings manually. Having the methods
available for manipulating the text makes a huge difference.

4) Though a separate issue, the lack of full text justification is
significant. The early versions of the rich textbox control (including the
Microsoft one) do not support full text justification. But the later
versions (based on a newer version of the RichEdit Window Class) do support
full text justification, as well as other advanced features. Thus, even
though the Microsoft Rich Text is HTML and not RTF, someone going into it in
2007 would expect that features that have been available with the RichEdit
Window Class would be available in the new MS Rich Text. But they're not.
Thus, again, for someone considering upgrading to A07, the lack of advanced
formatting capabilities would be a significant issue for them, since, if
they currently use those features, the A07 rich text would be a downgrade
for them.

5) Continuing on the last point, the MS rich text feature doesn't provide
the ability to set margins, tab stops, etc., etc. One can just apply the
code manually, as with the bold issue. But, again, these methods are
available in rich textbox controls, and have been for many years. The MS
rich text feature seems more geared towards just allowing users to work with
formatted text in forms and reports, and not for doing any serious work with
rich text. That feature (allowing users to work with formatted text) is a
great feature, and I'm glad it's there for the users. But someone upgrading
to A07 to use the rich text feature for anything serious would be sorely
disappointed at the lack of functionality it provides.

Thus, to me, all of the above are significant issues when considering
upgrading to A07 to use the rich text capabilities. To me, they make it not
worthwhile, and I'll probably just go with a third-party control (other than
the MS Rich Textbox control that I'm currently using) instead. So I think
the issues are significant.

Neil
"Allen Browne" <Al*********@SeeSig.Invalidwrote in message
news:46***********************@per-qv1-newsreader-01.iinet.net.au...

Okay: I'm not sure I see this as a huge deficit. Easy enough to knock up a
couple of functions to add the <band </bat SelStart and SelEnd etc if
you need that.

PlainText() is built in for going the other direction.

Perhaps it would be fair to say that the new HTML "rich text" is not
mature yet. Issues such as the way the spell-checker messes up the field
bother me more.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Neil" <no****@nospam.netwrote in message
news:nL****************@newssvr22.news.prodigy.net ...

>Yes, I suppose one can add the HTML codes manually, which works fine for
simple things like bolding, but would get a little dicier with complex
formatting.

But what I meant was that in RTF controls (such as the Microsoft Rich
Textbox control, or third-party controls, such as FMS's), you can change
the format of the text programmatically using methods built into the
control. For example, to set the below bold text, one would use the
SelBold method in conjuction with SelStart and SelLength. Again, with
simple examples it shouldn't matter; but with complex formatting it makes
a big difference to let the control set the RTF or HTML code for you.

So, it's those methods that appear to be missing from controls designated
as "rich text" in Access 2007. Having to set the HTML manually would be
huge deficit, especially since rich text controls that have been
available for many years (and are still available) provide the methods to
do it automatically.

Neil

[Tom van Stiphout]

On Sat, 16 Jun 2007 12:19:53 GMT, "Neil" <no****@nospam.netwrote:

Couldn't you continue to use the old rich text control? You wouldn't
have to change any code.

-Tom.
<clip>

>
Thus, to me, all of the above are significant issues when considering
upgrading to A07 to use the rich text capabilities. To me, they make it not
worthwhile, and I'll probably just go with a third-party control (other than
the MS Rich Textbox control that I'm currently using) instead. So I think
the issues are significant.

Neil

<clip>

[Neil]

The point was whether it was worthwhile to upgrade to A07 in order to use
the built-in rich text capabilities. Using built-in features is usually
preferred to using an ActiveX control.

Also, the MS Rich Textbox control has problems after A2000. So it's either
go with a different control or use the A07 built-in rich text capabilities.
Plus, the MS Rich Textbox control doesn't support full text justification
(which I need), so I was hoping the A07 rich text capabilities did. But,
apparently, they're not ready for prime time, and they don't.
"Tom van Stiphout" <no*************@cox.netwrote in message
news:fg********************************@4ax.com...

On Sat, 16 Jun 2007 12:19:53 GMT, "Neil" <no****@nospam.netwrote:

Couldn't you continue to use the old rich text control? You wouldn't
have to change any code.

-Tom.
<clip>

>>
Thus, to me, all of the above are significant issues when considering
upgrading to A07 to use the rich text capabilities. To me, they make it
not
worthwhile, and I'll probably just go with a third-party control (other
than
the MS Rich Textbox control that I'm currently using) instead. So I think
the issues are significant.

Neil

<clip>

[Rick Brandt]

Neil wrote:

The point was whether it was worthwhile to upgrade to A07 in order to
use the built-in rich text capabilities. Using built-in features is
usually preferred to using an ActiveX control.

Also, the MS Rich Textbox control has problems after A2000. So it's
either go with a different control or use the A07 built-in rich text
capabilities. Plus, the MS Rich Textbox control doesn't support full
text justification (which I need), so I was hoping the A07 rich text
capabilities did. But, apparently, they're not ready for prime time,
and they don't.

Point 1) In my opinion rich text has very little *real* value in a database
application. It screws you on just about anything that a database needs to do
with data. ANY limitations encountered when using Rich Text should be
attributed to using a database to store data not well suited to databases in the
first place. I.e . rich rext belongs in word processing software, not in
database tables.

Point 2) The rich text in Access 2007 is designed from the get-go to be
compatible with Sharepoint. MS couldn't care less about whatever previous Rich
Text control you might have been using and what features it provided. In other
words, previously there was nothing (native), and now there is something for
dealing with formatted text. Anything you were accomplishing before with
non-native controls is beside the point.

They might make the control more feature rich in the future, but only as
required to fit the vision that MS has for the feature in their broader
strategic goals. How *other* rich text controls work is not likely to be much
of a consideration.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Neil]

Wow, you sound pretty hostile.

First, I think what other rich text controls had before *is* significant.
Microsoft, in their documentation, states that now that rich text is
provided native to Access you no longer need to use an ActiveX control to
use rich text. So, clearly, they intend for the native rich text to replace
rich text controls.

Second, this isn't a discussion about what Microsoft "should" or "shouldn't"
do. It's a discussion about what capabilities are provided by the new rich
text feature in Access, and whether those could be used as a replacement for
an ActiveX control. The end of this discussion (where you are now coming in)
is that, no, the rich text capabilities are not as good as what's available
with ActiveX controls in many ways, and the Access rich text capabitlies
are, in fact, very rudimentary.

Third, regarding your point that rich text has no place in databases:
clearly you have a very narrow view of what databases can be used for. And,
I suppose, since you've never come across a situation where you needed rich
text in a database, your perspective on the situation is somewhat narrow.

As for that rich text belongs in a word processor, that's exactly the
position my client started at about ten years ago. They have a series of
formatted documents, each one of which describes one of their items. Since
they needed to be able to apply bold and italic within paragraphs, they
could not produce these as Access reports. So they created a series of Word
documents, which is in accordance with what you are recommending. There are
currently several thousand of these documents.

The problem is that they need to use the text in more than one format. So,
as a result, for each document, they need to save it as a sister document,
edit that sister document, even though both share most of the same text.
They are also in need of a couple more formats, which means that for each
item there will be a set of four documents, each of which have most of the
same text, but different format. These documents need to be manually
managed.

Instead of manually creating Word documents and making copies of the
documents every time a new format is needed, a far superior approach is to
break the documents down to their key text components, store those in the
database, using rich text, and mix and match them as needed to create
whatever documents are needed when they're needed.

In addition to alleviating the need to create multiple copies of each
document, it also allows the text in the documents to be easily searched,
filtered, reported on, etc., etc. Also, being able to view the description
in an Access report, using rich text (again, so that bold and italic within
a paragraph can be applied) is much, much faster and uses far less overhead
than opening Word through automation and viewing the document in Word. And,
if the format of a type of document ever changes, that format can be easily
applied by simply changing the Access report that creates the document,
rather than manually going into several thousand documents and adjusting
them.

So I would have to strongly disagree with you that rich text has very little
real value in a database application, and that rich text should only be
stored in word processing software, not in database tables. In my client's
application, storing the rich text in word processing software (as they have
been doing) is definitely *not* the way to go, and using rich text controls
within Access to be able to generate the documents on the fly is a far
superior approach. I'd have to strongly disagree with you there.

But I wonder why the hostile tone in your message? Are you trying to defend
Microsoft, and you feel that I was bashing them or Access 2007 in my
message? Otherwise, I fail to understand why you took such a hostile tone in
a technical discussion.

Neil
"Rick Brandt" <ri*********@hotmail.comwrote in message
news:zj*****************@newssvr22.news.prodigy.ne t...

Neil wrote:

>The point was whether it was worthwhile to upgrade to A07 in order to
use the built-in rich text capabilities. Using built-in features is
usually preferred to using an ActiveX control.

Also, the MS Rich Textbox control has problems after A2000. So it's
either go with a different control or use the A07 built-in rich text
capabilities. Plus, the MS Rich Textbox control doesn't support full
text justification (which I need), so I was hoping the A07 rich text
capabilities did. But, apparently, they're not ready for prime time,
and they don't.

Point 1) In my opinion rich text has very little *real* value in a
database application. It screws you on just about anything that a
database needs to do with data. ANY limitations encountered when using
Rich Text should be attributed to using a database to store data not well
suited to databases in the first place. I.e . rich rext belongs in word
processing software, not in database tables.

Point 2) The rich text in Access 2007 is designed from the get-go to be
compatible with Sharepoint. MS couldn't care less about whatever
previous Rich Text control you might have been using and what features it
provided. In other words, previously there was nothing (native), and now
there is something for dealing with formatted text. Anything you were
accomplishing before with non-native controls is beside the point.

They might make the control more feature rich in the future, but only as
required to fit the vision that MS has for the feature in their broader
strategic goals. How *other* rich text controls work is not likely to be
much of a consideration.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Scott McDaniel]

On Sat, 16 Jun 2007 21:51:14 -0500, "Neil" <no****@nospam.netwrote:

>Wow, you sound pretty hostile.

First, I think what other rich text controls had before *is* significant.
Microsoft, in their documentation, states that now that rich text is
provided native to Access you no longer need to use an ActiveX control to
use rich text. So, clearly, they intend for the native rich text to replace
rich text controls.

<snippity snip snip>

>But I wonder why the hostile tone in your message? Are you trying to defend
Microsoft, and you feel that I was bashing them or Access 2007 in my
message? Otherwise, I fail to understand why you took such a hostile tone in
a technical discussion.

I don't think Rick's tone was hostile. He makes some valid points, and I'd agree with him regarding storing richtext in
a database. Your situation seems to warrant doing so, but (as the saying goes) to each his own.

You're correct that the rich text control doesn't provide much in the way of "working with rich text", but that's
because Access isn't a word processing application.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

[Neil]

Well, again, the issue is: can the built-in Access rich text features
replace previous rich text ActiveX controls? Rick says they're not intended
to. I say that the Microsoft documentation says that they are intended to.
But that's the only issue. No one thinks that Access is a word processing
application, not even in anyone's wildest dreams. But there are rich text
ActiveX controls; and MS says that now you don't need them because rich text
is built into Access. So the question (and the only question I've been
discussing here, not the more philosophical ones of whether or not rich text
belongs in a database, or is Access a word processing application, etc.) --
the only question I've been discussing here, and no other question, is: can
the new built-in rich text capabilities replace the previous ActiveX rich
text controls as Microsoft says they can? I've concluded that they cannot.
Whether they should be, would be, could be, or whatever else is an entirely
different issue.

Neil

>
You're correct that the rich text control doesn't provide much in the way
of "working with rich text", but that's
because Access isn't a word processing application.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

[Rick Brandt]

Neil wrote:

Wow, you sound pretty hostile.

I re-read what I posted and don't see any hostility, but if you got that
impression then I apologize.

First, I think what other rich text controls had before *is*
significant. Microsoft, in their documentation, states that now that
rich text is provided native to Access you no longer need to use an
ActiveX control to use rich text. So, clearly, they intend for the
native rich text to replace rich text controls.

Yes, but only in the sense of providing some text formatting which Access 2007
does provide. The vast majority of users of Rich Text controls simply want to
be able to bold a word here and there. The more advanced features that you are
looking for would be desired by a much lower percentage of users and I wouldn't
be at all surprised in MS simply doesn't consider that a priority.

The pattern in recent Access releases has been to cater more and more to the
office worker and less and less to those doing serious application development.
It's not a strategy I agree with, but that is the reality. It is all about
fitting things to their "big picture" strategy and the flavor this month is
integration with sharepoint services. That is the reason they added multi-value
fields and that is the reason they implemented the Rich Text support in the
manner they did.

Second, this isn't a discussion about what Microsoft "should" or
"shouldn't" do. It's a discussion about what capabilities are
provided by the new rich text feature in Access, and whether those
could be used as a replacement for an ActiveX control. The end of
this discussion (where you are now coming in) is that, no, the rich
text capabilities are not as good as what's available with ActiveX
controls in many ways, and the Access rich text capabitlies are, in
fact, very rudimentary.
Third, regarding your point that rich text has no place in databases:
clearly you have a very narrow view of what databases can be used
for. And, I suppose, since you've never come across a situation where
you needed rich text in a database, your perspective on the situation
is somewhat narrow.

I believe data and the presentation of that data should be separate.

As for that rich text belongs in a word processor, that's exactly the
position my client started at about ten years ago. They have a series
of formatted documents, each one of which describes one of their
items. Since they needed to be able to apply bold and italic within
paragraphs, they could not produce these as Access reports. So they
created a series of Word documents, which is in accordance with what
you are recommending. There are currently several thousand of these
documents.
The problem is that they need to use the text in more than one
format. So, as a result, for each document, they need to save it as a
sister document, edit that sister document, even though both share
most of the same text. They are also in need of a couple more
formats, which means that for each item there will be a set of four
documents, each of which have most of the same text, but different
format. These documents need to be manually managed.

Sounds like they should be using HTML with CSS for the styling. That is what
web authors have been doing for years. The structured content is written
without regard to presentation and then CSS is used to apply styling at
presentation time. Different CSS applied to the same core document can provide
a multitude of different presentations without having to alter the content at
all.

Instead of manually creating Word documents and making copies of the
documents every time a new format is needed, a far superior approach
is to break the documents down to their key text components, store
those in the database, using rich text, and mix and match them as
needed to create whatever documents are needed when they're needed.

I would use a method that allowed styling to be applied to the content without
having to save multiple copies of it, but if what you're doing works for you
then fine.

In addition to alleviating the need to create multiple copies of each
document, it also allows the text in the documents to be easily
searched, filtered, reported on, etc., etc. Also, being able to view
the description in an Access report, using rich text (again, so that
bold and italic within a paragraph can be applied) is much, much
faster and uses far less overhead than opening Word through
automation and viewing the document in Word. And, if the format of a
type of document ever changes, that format can be easily applied by
simply changing the Access report that creates the document, rather
than manually going into several thousand documents and adjusting
them.
So I would have to strongly disagree with you that rich text has very
little real value in a database application, and that rich text
should only be stored in word processing software, not in database
tables. In my client's application, storing the rich text in word
processing software (as they have been doing) is definitely *not* the
way to go, and using rich text controls within Access to be able to
generate the documents on the fly is a far superior approach. I'd
have to strongly disagree with you there.

I was speaking in the broader sense rather than about your specific application.
Most users who will use the Rich Text feature will do so (IMO) in a way that
adds little real value to the app they are building and will in fact cause them
more problems than it is worth because they won't understand that they are no
longer storing what they see on the screen.

But I wonder why the hostile tone in your message? Are you trying to
defend Microsoft, and you feel that I was bashing them or Access 2007
in my message? Otherwise, I fail to understand why you took such a
hostile tone in a technical discussion.

Again, I was not trying to convey the idea that I AGREE with the directions MS
is taking or the reasons they are doing so. Only that from their perspective
Access previously had zero *native* handling for formatted text and now they
have that capability and have implemented it in a manner that supports where
they want to see Access going. I imagine that for someone doing the more
advanced stuff you are they would just recommend staying with an ActiveX
control.

I'm surprised you felt I was "defending" Microsoft. If there was any "tone" in
my post it was aimed more at them than at you. Personally I think that there is
very little that they have gotten right since Office 97. Particularly as it
relates to Access.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Neil]

>Wow, you sound pretty hostile.

>
I re-read what I posted and don't see any hostility, but if you got that
impression then I apologize.

OK. Maybe I took it the wrong way. No problem.

>First, I think what other rich text controls had before *is*
significant. Microsoft, in their documentation, states that now that
rich text is provided native to Access you no longer need to use an
ActiveX control to use rich text. So, clearly, they intend for the
native rich text to replace rich text controls.

Yes, but only in the sense of providing some text formatting which Access
2007 does provide. The vast majority of users of Rich Text controls
simply want to be able to bold a word here and there. The more advanced
features that you are looking for would be desired by a much lower
percentage of users and I wouldn't be at all surprised in MS simply
doesn't consider that a priority.

Aye, but there's the rub! They may have intended it to be only basic
formatting, but what they *said* was that you no longer need to use ActiveX
rich text controls. So the issue here (the only issue, from my POV) has
been: can the MS rich text features replace the rich text ActiveX controls?
The answer to that was not at all clear by looking at the MS documentation,
which is why I started this thread. Had it been clear in the documentation,
I would have said, "OK," and moved on. But the documentation gives the
impression that the new features are a replacement for ActiveX controls,
which they are not. The ambiguity of their statements was the reason for
this discussion.

>
The pattern in recent Access releases has been to cater more and more to
the office worker and less and less to those doing serious application
development. It's not a strategy I agree with, but that is the reality.
It is all about fitting things to their "big picture" strategy and the
flavor this month is integration with sharepoint services. That is the
reason they added multi-value fields and that is the reason they
implemented the Rich Text support in the manner they did.

>Second, this isn't a discussion about what Microsoft "should" or
"shouldn't" do. It's a discussion about what capabilities are
provided by the new rich text feature in Access, and whether those
could be used as a replacement for an ActiveX control. The end of
this discussion (where you are now coming in) is that, no, the rich
text capabilities are not as good as what's available with ActiveX
controls in many ways, and the Access rich text capabitlies are, in
fact, very rudimentary.
Third, regarding your point that rich text has no place in databases:
clearly you have a very narrow view of what databases can be used
for. And, I suppose, since you've never come across a situation where
you needed rich text in a database, your perspective on the situation
is somewhat narrow.

I believe data and the presentation of that data should be separate.

I believe they go hand-in-hand. Certainly, sometimes the presentation of
data is just an afterthought. But other times (as in the case here), the
presentation of data is the primarly purpose of the use of the data, and the
two can't be separated. So the presentation of the data is sometimes tightly
wound into how the data is stored (though not always).

>

>As for that rich text belongs in a word processor, that's exactly the
position my client started at about ten years ago. They have a series
of formatted documents, each one of which describes one of their
items. Since they needed to be able to apply bold and italic within
paragraphs, they could not produce these as Access reports. So they
created a series of Word documents, which is in accordance with what
you are recommending. There are currently several thousand of these
documents.
The problem is that they need to use the text in more than one
format. So, as a result, for each document, they need to save it as a
sister document, edit that sister document, even though both share
most of the same text. They are also in need of a couple more
formats, which means that for each item there will be a set of four
documents, each of which have most of the same text, but different
format. These documents need to be manually managed.

Sounds like they should be using HTML with CSS for the styling. That is
what web authors have been doing for years. The structured content is
written without regard to presentation and then CSS is used to apply
styling at presentation time. Different CSS applied to the same core
document can provide a multitude of different presentations without having
to alter the content at all.

Yeah except that that gets back to my core issue: the users need to be able
to apply bold and italics to individual words within a paragraph. That's the
main reason for not using Access reports in the first place. And, yes, they
can apply bold with <B>, etc.; but they don't want to do that (and that's
their prerogative). They want to be able to edit documents and apply bold
and italics just like they do in Word, without having to work with HTML
codes and the like. Thus, the rich text control or rich text feature gives
them that ability without having to use Word (which is a negative in many
way, per my last post).

>

>Instead of manually creating Word documents and making copies of the
documents every time a new format is needed, a far superior approach
is to break the documents down to their key text components, store
those in the database, using rich text, and mix and match them as
needed to create whatever documents are needed when they're needed.

I would use a method that allowed styling to be applied to the content
without having to save multiple copies of it, but if what you're doing
works for you then fine.

I was ambiguous in my use of the word "format" (because that's the way the
word is used by the client, and I was carrying over that usage). When I said
that a new document is needed when a new "format" is needed, I meant a new
format of the content, not a new format of the style.

In other words, one set of documents has the full text. Another set has
abbreviated text. In order to get the two sets they have to make a copy of
the first document and manually edit it down.

Alternatively, if the pieces of text are stored in Access memo fields, then
whatever kind of document they need can be assembled at runtime based on how
the document type (or "format") is defined.

So that wasn't entirely clear, since "format" is more generally used to
refer to the document style. But here I was using it to refer to the actual
content of the document, which changes between document types (one document
type being a subset of the other in terms of text).

Thus, without breaking the text down into the key blocks of text and then
reassembling those blocks as needed, one is stuck with multiple copies of
documents. Thus, using the database to store those blocks of text is a
superior method.

>

>In addition to alleviating the need to create multiple copies of each
document, it also allows the text in the documents to be easily
searched, filtered, reported on, etc., etc. Also, being able to view
the description in an Access report, using rich text (again, so that
bold and italic within a paragraph can be applied) is much, much
faster and uses far less overhead than opening Word through
automation and viewing the document in Word. And, if the format of a
type of document ever changes, that format can be easily applied by
simply changing the Access report that creates the document, rather
than manually going into several thousand documents and adjusting
them.
So I would have to strongly disagree with you that rich text has very
little real value in a database application, and that rich text
should only be stored in word processing software, not in database
tables. In my client's application, storing the rich text in word
processing software (as they have been doing) is definitely *not* the
way to go, and using rich text controls within Access to be able to
generate the documents on the fly is a far superior approach. I'd
have to strongly disagree with you there.

I was speaking in the broader sense rather than about your specific
application. Most users who will use the Rich Text feature will do so
(IMO) in a way that adds little real value to the app they are building
and will in fact cause them more problems than it is worth because they
won't understand that they are no longer storing what they see on the
screen.

That's probably true. But I, of course, was just referring to my
application.

>

>But I wonder why the hostile tone in your message? Are you trying to
defend Microsoft, and you feel that I was bashing them or Access 2007
in my message? Otherwise, I fail to understand why you took such a
hostile tone in a technical discussion.

Again, I was not trying to convey the idea that I AGREE with the
directions MS is taking or the reasons they are doing so. Only that from
their perspective Access previously had zero *native* handling for
formatted text and now they have that capability and have implemented it
in a manner that supports where they want to see Access going. I imagine
that for someone doing the more advanced stuff you are they would just
recommend staying with an ActiveX control.

And it would be so very nice if they would just say that! Then people like
me wouldn't have to post messages like this saying, "Does anyone know if the
A07 rich text capabilities support this and that?" But when they make a
carte blanche statement saying, "You no longer need to use an ActiveX
control because rich text capabilities are built into Access 2007," it's
extemely misleading.

In fact, the only place I've seen in the MS documentation where it talks
about using an ActiveX control vs. the native rich text capabilities are in
a discussion of if you have existing RTF data. There MS says that you can't
use the RTF codes with the HTML format of the rich text capabilities, so you
should keep your ActiveX control. But nowhere does it say, "If you need
advanced formatting capabilities, then you should stick with an ActiveX
control." So they do discuss in at least one place the use of an ActiveX
control vs. the native A07 rich text features. But there's no mention of
limited functionality in the native features or any need to use an ActiveX
control for that reason -- just the fact that you can't use your existing
RTF data with the native rich text functionality.

>
I'm surprised you felt I was "defending" Microsoft. If there was any
"tone" in my post it was aimed more at them than at you.

I didn't think you were defending Microsoft. I was asking you if that was
the reason for your tone, since I couldn't understand why you would have
that tone otherwise. But, again, I probably misunderstood your tone.

Personally I think that there is very little that they have gotten right
since Office 97. Particularly as it relates to Access.

Yeah, Office 97 was great. Maybe 2007 will be good. I like some of the new
features, such as split forms, from what I've seen so far. But, who knows,
maybe it'll be a dog.

Neil

>
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[David W. Fenton]

"Neil" <no****@nospam.netwrote in
news:%R*******************@newssvr23.news.prodigy. net:

But nowhere does it say, "If you need
advanced formatting capabilities, then you should stick with an
ActiveX control."

So, what "advanced formatting" does your ActiveX control give you
that the A07 control lacks?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Neil]

Well, at the beginning of this thread was the question of whether A07
provided full text justification and the ability to manipulate the rich text
control (or textbox formatted as rich text) through methods such as SelBold,
etc., as well as the ability to concatenate multiple rich text boxes without
having to parse RTF or HTML code. Later, added to the list, are the ability
to specify a tab type other than left tab, and a myriad of other formatting
options.

If you haven't read through this thread, you may say, "What the heck do you
need those for in an Access database???" The answer is if you are using the
Access database to collect and collate data that will be saved as an RTF or
HTML document. In any case, I've gone to great length to explain my purpose
and have gone back and forth a bit over that, which is all contained above
in this thread.

Thanks,

Neil
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...

"Neil" <no****@nospam.netwrote in
news:%R*******************@newssvr23.news.prodigy. net:

>But nowhere does it say, "If you need
advanced formatting capabilities, then you should stick with an
ActiveX control."

So, what "advanced formatting" does your ActiveX control give you
that the A07 control lacks?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/