0x0D 0x07 counted as one?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Wallentin - 04 Feb 2005 20:33 GMT

HI!

I have created an application that interacts with Word documents through the
Window, Document, Range and Selection COM interfaces. It’s a C++ application
but I hope you VBA folks can help me with a minor problem :-)

My application was working very well until I encountered the strange 0x0D
0x07 (chr(13)chr(7)) combination used in tables.

The problem is not the control codes themselves. I ignore control codes
anyway. The problem is that the combination of these two codes is only
counted as one in the character count returned by the COM interfaces, but
they are returned as two!?

I’ll try to explain my problem through some pseudo code:

numCharsInDoc = Document.Range.End

caretPosition = Window.Selection.End

allText = Document.Range.Text

I an ordinary Word document the number of characters in my text buffer
(allText) would equal the returned character count (numCharsInDoc), and I
would be able to use the caret offset (caretPosition) as a pointer into my
buffer.

In a Word document with one or more tables, the number of characters in the
text buffer (allText) will be greater than the returned character count
(numCharsInDoc). In the numCharsInDoc (and in the caretPosition) variable the
0x0D 0x07 combination is counted as one but they are returned as two in the
text buffer. Given these circumstances I have no clue as to where my caret
offset is pointing…

-Is this a correct conclusion of what is happening?
-Would it be possible to some how get the correct character count?
-Are there any other special control code combinations that I ought to
know about?

I hope someone can help me on this. Any suggestions are more than welcome or
if someone have a link to some documentation on this subject…

Thanks in advance.

W.

Reply to this Message

Jezebel - 05 Feb 2005 02:56 GMT

chr(7) is the end-of-cell marker; every table cell, even if 'empty' contains
chr(13)chr(7). These are not independently selectable, which I guess is the
basis of your problem. You might be able to obtain a correct character count
by adding one for each table cell, although getting a count of table cells
isn't straightforward if you have to allow for non-uniform tables.

Why are you using the Window and Selection objects at all? When working with
Word from a remote application (I've done a lot of this from VB) life is
*much* simpler if you work exclusively with Range objects -- then this sort
of problem doesn't arise. You only need Window and Selection objects if you
want to interact with the user.

I don't know what other control sequences you might encounter, but there is
an end-of-row marker (you don't meet it using the normal ranges, but it must
be there somewhere); and the relation between paragraph ranges and frames,
and between paragraph ranges and anchored graphics, must also be coded
somewhere.

> HI!
>
[quoted text clipped - 47 lines]
>
> W.

Reply to this Message

Wallentin - 05 Feb 2005 08:53 GMT

Thanks for your input.

> chr(7) is the end-of-cell marker; every table cell, even if 'empty' contains
> chr(13)chr(7). These are not independently selectable, which I guess is the
> basis of your problem. You might be able to obtain a correct character count
> by adding one for each table cell, although getting a count of table cells
> isn't straightforward if you have to allow for non-uniform tables.

I thought a lot about different solutions where I change the returned
results. The best solution I think would be to strip al chr(7)s from the
buffer, this woul leave me with a valid character count and a valid caret
offset - or would it? This is my great concern, I do not like fixing problems
this way. How can I be sure that chr(7) are not used elsewhere and actually
counted? I would like to find a solution where the interfaces provide me with
the needed inforation.

> Why are you using the Window and Selection objects at all? When working with
> Word from a remote application (I've done a lot of this from VB) life is
> *much* simpler if you work exclusively with Range objects -- then this sort
> of problem doesn't arise. You only need Window and Selection objects if you
> want to interact with the user.

My application uses Microsoft Active Assibility to get hold of the Window,
which explains why I am using the Window interface. What I need to do from
this window is reading text, inserting text and highlighting text based onlow
level text handling ie integer pointers. How I do it does not matter, so if
you have any better ideas please let me know :-)

> I don't know what other control sequences you might encounter, but there is
> an end-of-row marker (you don't meet it using the normal ranges, but it must
> be there somewhere); and the relation between paragraph ranges and frames,
> and between paragraph ranges and anchored graphics, must also be coded
> somewhere.

See this is what warries me if I should choose to change the returned data.
As long as I cannot find all these control codes described somewhere (with a
note about which combinations are counted as one :-) I choose not to change
the returned data.

/Lasse

Reply to this Message

Jezebel - 05 Feb 2005 12:07 GMT

> My application uses Microsoft Active Assibility to get hold of the Window,
> which explains why I am using the Window interface. What I need to do from
[quoted text clipped - 3 lines]
> if
> you have any better ideas please let me know :-)

Reading and inserting text is done more easily by working directly with the
various range objects. You don't need pointers or windows to do any of this.
And you don't need to screw around with carats or cursors. This sort of
thing is trivial in VB -- you seem to be making quite a meal of it in C,
which surprises me. C is supposed to be simpler still.

Not sure what you mean by highlighting here ... are you displaying the text
to the user?

Reply to this Message

Wallentin - 06 Feb 2005 15:01 GMT

> Reading and inserting text is done more easily by working directly with the
> various range objects. You don't need pointers or windows to do any of this.
> And you don't need to screw around with carats or cursors. This sort of
> thing is trivial in VB -- you seem to be making quite a meal of it in C,
> which surprises me. C is supposed to be simpler still.

Well I am using Range objects. I just have to do it in a low level way
because I am implementing an interface used in a lot of different Windows
applications. For example my application works in notepad two, wher you do
not have the same structure.

I do not think I am making it complicated at all - as you suggest. What I
need to do is read, insert and select text in a given document based on
interger offsets. Basicly this can be done with the following pheuso lines of
code:

//Read text into buffer given a start and end integer offset:
buffer = Document.Range(start, end).Text

//Replace text based on a given a start and end integer offset:
Selection.SetRange(start, end)
Selection.SetText(someStr)

//Select text based on a given a start and end integer offset:
Selection.SetRange(start, end)

Theese lines do not seem complicated to me. They work fine. The only problem
is still figuring out where the cursor is in the read text, when tables are
involved which was the original question posted :-)

> Not sure what you mean by highlighting here ... are you displaying the text
> to the user?

Sorry what I meant was plain text selection. Selecting some part of the
text. Again specified by two integers indicating the start and end of the
wanted selection.

/Wallentin

Reply to this Message

Rate this thread: