Re: Access 2007 Rich Text Deficiencies?

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




.

Relevant Pages

  • Re: Access 2007 Rich Text Deficiencies?
    ... I think what other rich text controls had before *is* significant. ... provided native to Access you no longer need to use an ActiveX control to ... text in a database, your perspective on the situation is somewhat narrow. ... The problem is that they need to use the text in more than one format. ...
    (comp.databases.ms-access)
  • Re: Memo Underline
    ... I tried to add a MS Rich ... Textbox Control 6.0and I got an err. ... does not support this ActiveX control. ... Rick Brandt, Microsoft Access MVP ...
    (microsoft.public.access.forms)
  • Using Rich Text Box control
    ... I'm using access 2K3 in 2000 format. ... Created report and added in a Microsoft ... Rich Text box control. ...
    (microsoft.public.access.reports)
  • Re: attachment placement
    ... It is being displaed in-line when you are composing in Rich Text format. ... can control the default message format by going to Tools-> Options-> tab ... > header or how you can control this. ...
    (microsoft.public.outlook.general)
  • Re: Creating browser sniffer with ASP.Net
    ... I think you're going to need an ActiveX control or a rich .NET client to get ... The control would be along the lines of what they use at Windows Update. ...
    (microsoft.public.dotnet.framework.aspnet)