Results 1 to 11 of 11
  1. #1
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Range assignment in IncludeText field

    My Word97SR2 hangs on a RANGE assignment.

    I can duplicate this at will when the IncludeText field is in my home page DOCument, but not on all Includetext fields.

    Single-stepping through the code in VBE the cursor and all activity disappears. Ctrl-Break, or Esc have no effect.


    <pre>Sub HANGMachine()
    Dim prg As Paragraph
    For Each prg In ActiveDocument.Paragraphs
    Dim rng As Range
    ' Hangs on next statement in a 1-paragraph document with an "INCLUDETEXT"field.
    Set rng = prg.Range.Sentences(1)
    Next prg
    End Sub
    </pre>

    Attached Files Attached Files

  2. #2
    JustCallMeAl
    Guest

    Re: Range assignment in IncludeText field

    If the attached is supposed to contain:

    <hr>1-paragraph document with an "INCLUDETEXT"field<hr>

    It doesn't. The command activedocument.Paragraphs.Count in the Immediate window gives "7" as the number of paragraphs, whether viewing just the code or the results.

    Secondly, when you are working with Field codes, you need to work with the Fields object.

    Thirdly, even if you do work with the Fields object, i.e., activedocument.fields(1).results.sentence(1), you will still lock up. [img]/forums/images/smilies/smile.gif[/img]

    Try ActiveDocument.Tables(1).Range.Sentences(1) instead. No Lockie.

  3. #3
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    Hmmm. Al, Thanks for the response, I think (grin!)

    > If the attached is supposed to contain:1-paragraph document with an "INCLUDETEXT"field

    It does. Or at least, it did before I u/l it and it still does here.


    > The command activedocument.Paragraphs.Count in the Immediate window gives "7" as the number of paragraphs, whether viewing just the code or the results.

    Odd. This IS the number of paragraphs visible when I look at the document. The Include data is small file consisting of a two-row table with three paragraphs of data in the second row, There is a paragraph mark at the head and foot of the table; the Includetext field seems to do this. The small document being included has the perennial paragraph-at-end-of-document. There are various cell and row markers visible. A case can be made for seven paragraph marks. I doubt MSoft, but I don't doubt you.


    > Secondly, when you are working with Field codes, you need to work with the Fields object.

    Can't be done; or at least, can't be detected with certainty, as we all<A target="_blank" HREF=http://www.wopr.com/cgi-bin/w3t/showflat.pl?Cat=&Board=vb&Number=39243&page=&view= &sb=&o=&vc=1> hashed</A> over a while back. Doubly-@#$!%.


    > Thirdly, even if you do work with the Fields object, i.e., activedocument.fields(1).results.sentence(1), you will still lock up. [img]/forums/images/smilies/smile.gif[/img]

    Well, I knew THAT!


    > Try ActiveDocument.Tables(1).Range.Sentences(1) instead. No Lockie.

    Good suggestion. I'm just disappointed that it doesn't work for me. I placed a test:
    <pre> Dim prg As Paragraph
    For Each prg In doc.Paragraphs
    Dim rng As Range
    If prg.Range.Information(wdWithInTable) Then
    MsgBox "in table"
    Else
    Set rng = prg.Range.Sentences(1)
    (snip)
    </pre>

    but I dont get no message. It is as if my code says "this isn't a table (yet/really), it's a Field" (but see "hashed over" above).





    I haven't tried placing some text ahead of the field (as in "space space {includetext}") to see if that obviates the problem.

    I hate the idea of having to test for Fields, Tables, Ice Cream cones or whatever when processing paragraphs or sentences.

  4. #4
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    I forgot to ask. It looks as if you actually tried this. Are you using Word97SR2 or a later version?

    If you can get these tests (is in Field, is in Table) to work, I'd like to know.

  5. #5
    JustCallMeAl
    Guest

    Re: Range assignment in IncludeText field

    Yes I am using Word 97 SR2, and it did work as I previously posted.

  6. #6
    Gold Lounger
    Join Date
    Dec 2000
    Location
    Hollywood (sorta), California, USA
    Posts
    2,759
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    No lockie. No lock up. No problem.

    Your attached doc had one paragraph in it.

    Move the following out of the loop:

    Dim rng As Range
    Kevin <IMG SRC=http://www.wopr.com/w3tuserpics/Kevin_sig.gif alt="Keep the change, ya filthy animal...">
    <img src=/w3timages/blackline.gif width=33% height=2><img src=/w3timages/redline.gif width=33% height=2><img src=/w3timages/blackline.gif width=33% height=2>

  7. #7
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    >No lockie. No lock up. No problem.
    No porridge for YOU, Mary Jane.


    I'm glad that you had no problem; were you using Word97SR2, or have you moved on to one of these new-fangled versions? I'm not thinking of upgrading beyond Word97SR2 this weekend, but if it turns out I have a Word97SR2 bug that can't easily be replicated in Word2000, then I can comment my fudge as a "fix for Word97SR2 bug".


    >Your attached doc had one paragraph in it.

    I think that this depends on how you view the paragraph, whether Field Codes are displayed or not, whether you're using your eyes or the Immediate Window (a la Al).



    >Move the following out of the loop:
    >Dim rng As Range


    Now, Kevin, we've been through too much together to re-hash this (grin!) but what they heck!

    I hate any kind of coding chunk that extends beyond one page of paper or one screen of monitor. I still write them (they get away from me so) but I still hate them.

    For a decently small (one-screen) procedure, I do like all the declarations up front. For an indecently large procedure I have grown into the habit of declaring an identifier only where it is needed when it is needed. A working variable, such as a ForNext counter, that is activated ONLY at a level-three nesting place can be safely defined there, so that the reader isn't overcome by a great raft of definitions at the head of the procedure; the reader need assimilate only what the reader needs.

    Another argument: as procedures grow (we've had a lot of rain here this month) it is somewhat easier to cut out the inner portion to create a decently small procedure if working variables are defined geographically local to their use.

    For two-pass translators, such as is VBA, which makes one pass to collect the data definitions and then another pass to translate, it doesn't matter where the data is defined (from the interpreter's point of view).


    Apart from the question of readability (an important matter) jave you a functional reason for moving the definition towards the head of the procedure?

  8. #8
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    (later: not a terribly good solution. I implemented it this morning and it immediately bypassed all regular paragraphs that contained {XE}. I'll have to be more specifi and say "if the paragraph contains an {Includetext}, avoid that text like the plague", possibly making use of range.start and range.end as before .....)


    OK, Al, armed with your goading (vbGrin) I persevered. I'm sure that this solution is not complete, but it goes some way towards avoiding the hang AND identifying when I'm in a field, something I couldn't get right over a month ago.

    It is, of course, a fudge, since we can't get range.information.HonestlyWithinField.

    I daresay I'll refinf this as I learn more.


    Besides not hanging the machine, this solution gives me an advantage - it's from my Precis generator - being able to bypass Included files is a handy option for me, since now I can precis just the native text and disregard common text. The same will hold true for some other applications of mine. I'll spend the night deep in thought .....


    I'm re-attaching the template file bug.dot which holds the sample code displayed here.


    <pre>Sub NOHANGMachine()

    ' Skip character data until this range position is passed.
    Dim lngNext As Long
    lngNext = -1

    Dim prg As Paragraph
    For Each prg In ActiveDocument.Paragraphs

    prg.Range.Select 'useful when debugging/single-stepping

    If prg.Range.Start < lngNext Then
    MsgBox "Bypassing fields" ' because we already located a field.
    Else
    If prg.Range.Fields.Count > 0 Then ' we are about to step into it!
    MsgBox "skipping fields"
    ' obtain the end-point of the first field as text
    lngNext = prg.Range.Fields(1).Result.End
    ' but if the field itself is longer, well, use it!
    If lngNext < prg.Range.End Then
    lngNext = prg.Range.End
    Else
    End If
    Else
    ' We are well-clear of any field-related stuff.
    Dim rng As Range
    Set rng = prg.Range.Sentences(1)
    MsgBox rng.Text ' normal processing
    End If
    End If
    Next prg
    End Sub
    </pre>

    Attached Files Attached Files

  9. #9
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    Thanks to Al for goading me into this. Below is a solution to my immediate problem - I want to be able to loop through a document returning either (1) each paragraph or (2) each sentence or (3) each paragraph's 1st sentence. The solution below addresses (3), but you could, and I will, adapt it to a more general solution.

    Al: I tested it with a table coming in as a result of the Includetext field, and with a table outside an Includetext field. In both those cases one cell of the table contained an Includetext field anyway.

    <pre>Public Function rngGetNext1stSentenceOutsideIncludeFields(prg As Paragraph) As Range

    ' Procedure: rng1stSentenceOutsideIncludeFields
    ' Description: Locate all un-Included text.
    ' Copyright: Chris Greaves Inc.
    ' Inputs: DOCUMENT.
    ' Returns: RANGE with special settings.
    ' Assumes: Nothing
    ' Side Effects:
    ' Tested: By the calls below.

    ' Method:
    ' This early version is hard-coded to return All But {INCLUDETEXT} fields.
    ' A later version will accept a list of optional Field types.
    '
    ' A STATIC variable is used to hold a limit of any existing {INCLUDETEXT} field.
    ' Until this limit is reached we will return "failure"
    ' Once this limit is passed, we will return "success"
    '
    ' Success will be a valid range.
    ' Failure will be defined by setting the Range.End values to zero.

    ' Skip character data until this range position is passed.
    Static lngNext As Long
    If lngNext = 0 Then lngNext = -1 ' First entry

    ' Set the default result
    Set rngGetNext1stSentenceOutsideIncludeFields = prg.Range

    prg.Range.Select 'useful when debugging/single-stepping

    ' Can we establish a reason to avoid this text?
    If prg.Range.Fields.Count > 0 Then ' we are about to step into it!
    ' Are any of the fields including text?
    Dim iFld As Integer
    For iFld = 1 To prg.Range.Fields.Count
    If prg.Range.Fields(iFld).Type = wdFieldIncludeText Then
    ' skipping fields: setting the end-marker.
    ' obtain the end-point of the first field as text
    If lngNext <= prg.Range.Fields(1).Result.End Then
    lngNext = prg.Range.Fields(1).Result.End
    ' but if the field itself is longer, well, use it!
    If lngNext < prg.Range.End Then
    lngNext = prg.Range.End
    Else
    End If
    Else
    End If
    Exit For
    Else
    End If
    Next iFld
    Else
    End If

    ' Do we have a continuing reason to avoid this text?
    If prg.Range.Start < lngNext Then
    ' Bypassing fields because we already located a field.
    rngGetNext1stSentenceOutsideIncludeFields.End = 0
    Else
    ' We are well-clear of any field-related stuff.
    Dim rng As Range
    Set rng = prg.Range.Sentences(1)
    End If
    'Sub TESTrngGetNext1stSentenceOutsideIncludeFields()
    ' Dim prg As Paragraph
    ' For Each prg In ActiveDocument.Paragraphs
    ' Dim rng As Range
    ' Set rng = rngGetNext1stSentenceOutsideIncludeFields(prg)
    ' If rng.End = 0 Then ' we are bypassing fields
    ' Else
    ' MsgBox rng.Text
    ' End If
    ' Next prg
    'End Sub
    End Function
    </pre>


  10. #10
    Gold Lounger
    Join Date
    Dec 2000
    Location
    Hollywood (sorta), California, USA
    Posts
    2,759
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    What is the matter with Mary Jane?

    She's putting rice (pudding) in her loops again...

    I have no problem with declaring variables all over the place, but in a loop? Seems odd and I wondered if it was causing your problem.

    Oh well. If it makes the code more readable... <img src=/S/salute.gif border=0 alt=salute width=15 height=20>

    BTW, I'm still code-based in Word 97 SR-2
    Kevin <IMG SRC=http://www.wopr.com/w3tuserpics/Kevin_sig.gif alt="Keep the change, ya filthy animal...">
    <img src=/w3timages/blackline.gif width=33% height=2><img src=/w3timages/redline.gif width=33% height=2><img src=/w3timages/blackline.gif width=33% height=2>

  11. #11
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Range assignment in IncludeText field

    > I wondered if it was causing your problem

    It's good to wonder, or, in the case of my code, to STARE and wonder (grin!). usually when code of any kind bites me I'll take all the wonder i can get. We know that sometimes when you kick something for no real reason at all, you hear a rattle that tells you something.

    I think the hang was related to the table and/or the {Includetext} field.




    > If it makes the code more readable

    Debatable. For me it is more readable when my procedures are getting too large; localising the definition shields me from a zillion DIM statements up ftont that may not concern me. The correct answer to my posting was, of course, "Chris, it sounds as if this procedure is too large".

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •