locked
Hyphen in automated caption not recognized by Find RRS feed

  • Question

  • I found a problem while working with the way Captions are processed in Word.

    Inserting a formatted Caption of the format: Table 1.2.3-1 My Table Name

    where 1.2.3 is the Heading Level controlled via a { STYLEREF 3 \s } Field followed by a "-" (hyphen) followed by a 1 which is sequence controlled via a {SEQ Table \* ARABIC \s 3 } field. Looks daunting but its built-in, standard stuff.

    Now here's where it goes sideways. I'm running a Find thru the Doc to match a String that includes the Table number as text, e.g., Table 1.2.3-1. The Doc contains Tracked Changes but not in the range that would otherwise compromise the Find's ability to locate a successful match. Regardless, Find unfortunately fails because that little hyphen in the Doc's Table caption number (not the search string) is instead interpreted by Word as a Space character during the Find despite being displayed as a hyphen.

    Here's how to verify.

    1. Create a paragraph of text that includes an embedded Reference of the Table Number of a captioned Table elsewhere in the Doc.
    2. Now make some Tracked Changes elsewhere in the Doc.
    3. Copy the paragraph from Step 1 and paste into an Excel cell.
    4. Examine the Table number in Excel and see that the hyphen is replaced with a space, i.e., character code 32.
    5. Fail = the search string's hyphen is not equal to the Doc's space.

    Hmm, that's why the Find is failing. This does not happen when there are no Revisions in the Document.

    Originally posted to MS Answers: How to tell Word to interpret content as if all Revisions are Accepted?"

    • Edited by tocguy001 Saturday, February 10, 2018 4:46 PM
    Saturday, February 10, 2018 4:41 PM

All replies

  • Hi,

    Which version of Microsoft Word do you use? I couldn't reproduce this issue when testing within my Office 2016.

    Could you share a sample file to us so that we can test with it in case we have missed something here? If possible, you can send the sample file to GBSD TN Office Information Collection ibsofc@microsoft.com. (Please include the thread URL in the message so that we can easily identify your email)

    Thanks,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Monday, February 12, 2018 12:14 PM
  • O/S: 7 Enterprise x64

    Office: 2013 Pro+ x32

    Apparently the Doc having other Tracked Changes is not a factor after all. The issue persists regardless. Sample file sent to the proscribed email as requested.

    • Edited by tocguy001 Monday, February 12, 2018 4:31 PM
    Monday, February 12, 2018 4:18 PM
  • Hi,

    Double checked the mailbox but haven't found your message. Did you include the thread URL in the message? Could you try sending it again? Appreciate your time.

    Regards,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, February 15, 2018 8:21 AM
  • It's because in this case, the "hyphen" is actually a non-breaking hyphen (character 30) not, e.g., the "minus-hyphen (character 45) you get when you type a minus sign.

    If you copy the hyphen into the Find box, what you get may look like a space, but I am not sure exactly what it is - if you copy *that* character and paste it back into the document, Word does not seem to paste anything at all.

    If you type a "-" into the Find box, Word should match both "-" and the non-breaking hyphen (and possibly other types of hyphen as well. If you need to search specifically for the non-breaking hyphen, I think you can use ^30, or ^~ if you are using wildcards.

    Not sure if that helps you with this problem though!

    [FWIW If I paste the caption (or a copy made through the referencing facility) into an Excel cell, I either get

     a. a thing that looks like a hyphen but when examined using a formula (e.g. =CODE(MID(A1,13,1)) or whatever) returns 63 ("?") which suggests it is something else. That happens if I paste directly into a cell

     b. a thing that looks like a space and returns 32 when examined the same way, if I paste into the formula box (and Excel doesn't complain)

    So I suspect that examining the characters in Excel is not telling you anything useful. Selecting the character and using Word VBA (e.g. ?ascw(selection) in the immediate pane) is probably more helpful.



    Peter Jamieson


    Saturday, February 17, 2018 12:26 PM
  • Hi Peter,

    Thx for verifying this peculiar behavior.

    My testing produces different results depending upon how pasting into Excel is performed or when examining the selection in immediate mode. Excel ID's that character as code 32 when opening the cell before pasting, i.e., the space character; and ID's it as code 63 when pasting without opening the cell first. So, that's an Excel issue. Conversely, Word ID's the character as ASCII 30; a record separator in Immediate mode. What a bunch of crap!

    So, I see this incongruent behavior as a problem not only with Excel and Word but also a problem with Office.

    1. Word's Caption dialog explicitly states that the separating character is a "hyphen". Not a space, or non-breaking hyphen, or a Record Separator (ascii 30), or question mark (ascii 63).
    2. Using a Reference as the seed for a search should not change the seed midstream. That's just bad practice. This applies to both Word and Excel but each produces different results.

    These clunky perturbations are always such a joy to "discover". :(

    I hope MS reads your post where you explain that the hyphen is ASCII character 45 and not any of these other ascii characters that they chosen to change it to. How does this feature support interoperability I rhetorically wonder.

    Monday, February 19, 2018 4:19 PM