T
Tony Logan
I've written a macro that identifies all text boxes in a document, then
extracts the data from each text box and makes it normal paragraph text that
appears (approximately) as the next paragraph after that particular text
box's respective anchor.
I'm currently doing this by identifying each text box, converting it to a
frame, then deleting the frame so that the text box data becomes a normal
paragraph.
The reason I chose to convert the text boxes to frames was simply because
there seemed to be more ways to manipulate frames and the data therein than
text boxes (read "this was the only way I knew how to do what I wanted to
do").
However, when a text box appears within a table, converting it to a frame
splits the table, and that's a no-no for our overall process of handling the
data. I thought a solution might be to look one character in front of and one
character behind the frame, and if both of those selection points are in
tables, move the frame data after the second table, then join the two tables.
But the amount of code required for this solution seems pretty substantial
(at least the way I've written it), plus there's a fair chance of an error
when searching for tables before and after the frame.
I'd leave the text boxes as text boxes if I could figure out a way to detect
whether they're in a table or not; however, this seems dependent on how the
user inserts them, and we have no control over this. For instance, if a user
sets the text box Text Wrapping option to "In front of text," testing for
whether the text box was within a table would return false, which leads back
to part of the reason why I chose to convert the text boxes to frames. But
then converting to frames introduces the split table problem...
Just curious if anyone has a better suggestion.
extracts the data from each text box and makes it normal paragraph text that
appears (approximately) as the next paragraph after that particular text
box's respective anchor.
I'm currently doing this by identifying each text box, converting it to a
frame, then deleting the frame so that the text box data becomes a normal
paragraph.
The reason I chose to convert the text boxes to frames was simply because
there seemed to be more ways to manipulate frames and the data therein than
text boxes (read "this was the only way I knew how to do what I wanted to
do").
However, when a text box appears within a table, converting it to a frame
splits the table, and that's a no-no for our overall process of handling the
data. I thought a solution might be to look one character in front of and one
character behind the frame, and if both of those selection points are in
tables, move the frame data after the second table, then join the two tables.
But the amount of code required for this solution seems pretty substantial
(at least the way I've written it), plus there's a fair chance of an error
when searching for tables before and after the frame.
I'd leave the text boxes as text boxes if I could figure out a way to detect
whether they're in a table or not; however, this seems dependent on how the
user inserts them, and we have no control over this. For instance, if a user
sets the text box Text Wrapping option to "In front of text," testing for
whether the text box was within a table would return false, which leads back
to part of the reason why I chose to convert the text boxes to frames. But
then converting to frames introduces the split table problem...
Just curious if anyone has a better suggestion.
