Access 2007 Rich Text Deficiencies?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Neil

    Access 2007 Rich Text Deficiencies?

    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

    #2
    Re: Access 2007 Rich Text Deficiencies?

    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:

    The advantages you gain and problems you experience when upgrading to Microsoft Access 2007 from previous versions


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

    Comment

    • Neil

      #3
      Re: Access 2007 Rich Text Deficiencies?

      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" <jmishefskeNO@S PAMyahoo.comwro te in message
      news:467355b8$0 $28202$4c368faf @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:
      >
      The advantages you gain and problems you experience when upgrading to Microsoft Access 2007 from previous versions

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

      Comment

      • Allen Browne

        #4
        Re: Access 2007 Rich Text Deficiencies?

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

        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" <nospam@nospam. netwrote in message
        news:GFIci.1969 2$C96.15016@new ssvr23.news.pro digy.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" <jmishefskeNO@S PAMyahoo.comwro te in message
        news:467355b8$0 $28202$4c368faf @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)
        >>programmati c 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
        >'--------------------------

        Comment

        • Neil

          #5
          Re: Access 2007 Rich Text Deficiencies?

          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 programmaticall y 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" <AllenBrowne@Se eSig.Invalidwro te in message
          news:467360a2$0 $22430$5a62ac22 @per-qv1-newsreader-01.iinet.net.au ...
          Neil, I don't understand your comment about not being able to assign
          values programmaticall y.
          >
          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" <nospam@nospam. netwrote in message
          news:GFIci.1969 2$C96.15016@new ssvr23.news.pro digy.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" <jmishefskeNO@S PAMyahoo.comwro te in message
          >news:467355b8$ 0$28202$4c368fa f@roadrunner.co m...
          >>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)
          >>>programmat ic 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
          >>'--------------------------
          >

          Comment

          • Allen Browne

            #6
            Re: Access 2007 Rich Text Deficiencies?

            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" <nospam@nospam. netwrote in message
            news:nLJci.4123 $c06.275@newssv r22.news.prodig y.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 programmaticall y 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

            Comment

            • Neil

              #7
              Re: Access 2007 Rich Text Deficiencies?

              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" <AllenBrowne@Se eSig.Invalidwro te in message
              news:4673c5c0$0 $22410$5a62ac22 @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" <nospam@nospam. netwrote in message
              news:nLJci.4123 $c06.275@newssv r22.news.prodig y.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 programmaticall y 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
              >

              Comment

              • Tom van Stiphout

                #8
                Re: Access 2007 Rich Text Deficiencies?

                On Sat, 16 Jun 2007 12:19:53 GMT, "Neil" <nospam@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>

                Comment

                • Neil

                  #9
                  Re: Access 2007 Rich Text Deficiencies?

                  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.spam.tom774 4@cox.netwrote in message
                  news:fg48735i1d 9dc2vdbs5llf6dv 6uq2el3hj@4ax.c om...
                  On Sat, 16 Jun 2007 12:19:53 GMT, "Neil" <nospam@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>
                  >

                  Comment

                  • Rick Brandt

                    #10
                    Re: Access 2007 Rich Text Deficiencies?

                    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





                    Comment

                    • Neil

                      #11
                      Re: Access 2007 Rich Text Deficiencies?

                      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" <rickbrandt2@ho tmail.comwrote in message
                      news:zj0di.4275 $c06.3480@newss vr22.news.prodi gy.net...
                      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
                      >
                      >
                      >
                      >
                      >

                      Comment

                      • Scott McDaniel

                        #12
                        Re: Access 2007 Rich Text Deficiencies?

                        On Sat, 16 Jun 2007 21:51:14 -0500, "Neil" <nospam@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.co m
                        Custom Software design in Microsoft Access, VB.NET, ASP.NET, SQL Server, Oracle, MySQL

                        Comment

                        • Neil

                          #13
                          Re: Access 2007 Rich Text Deficiencies?

                          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.co m
                          www.infotrakker.com

                          Comment

                          • Rick Brandt

                            #14
                            Re: Access 2007 Rich Text Deficiencies?

                            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


                            Comment

                            • Neil

                              #15
                              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
                              >
                              >

                              Comment

                              Working...