Formatted Text vs Properties and Bookmarks (97-2003)

Topic

New Reply

I need to store information in properties, knowing that the text will also have superscripts, greek letters, etc.
So the only way to do this is to bookmark it, and link the prop to the bookmark (hate it, too fragile, wish there was some way to mark it as “undeletable”), so it can be used throughout the document (e.g. a product name followed by TM).

But to make the doc more reliable, I want to have the entry of those things in a dialog, or some controlled environment where they can’t accidentally nuke the bookmarks.
1) Ordinary text boxes just won’t cut it
2) The rich text box is marked as unsafe for Word 2002+
Why not make the stuff I’m entering a Word form? Because it needs to go in the header, for one, and because too much of the rest of the doc is free-form.

Any other suggestions? I was thinking about opening a dummy doc that’s a form, with buttons to make it look like a dialog.

Reply | Quote

Replies

Just to make sure I understand this: The user enters some kind of formatted text; you mark it with a Bookmark; you store the name of the bookmark in a Custom Document Property; when you want to cross-reference the original formatted text, you look in the document property to get the name of the Bookmark? Wow. That is going to create support issues for ordinary users.

This is going to sound cheesy, but… in my early days I created “forms” by setting up a data entry section, followed by the document body section. In the data entry section, there was a table, left cell description, right cell data, each data cell with a unique style name. In the document, I used STYLEREF fields to copy the contents of the data table. Users need some training on how to (1) update fields, and (2) use Page Setup with multiple sections (if you target is not plain paper), so there is a little bit of ramp-up you have to do. But it’s quick to edit, you can embed fields within fields in your data table by using STYLEREF fields to import previous data entries, and you can make the document final and presentable by unlinking all fields in the document and deleting the first section.

Now, this obviously isn’t for everyone, but for a quick in-house solution, I think it’s worth trying. When fields are inserted, by default they include the MERGEFORMAT switch, which in theory will coerce any superscript formattting back to the default for the paragraph in which it is being inserted. However, even without the switch, the STYLEREF fields seems to do that. (See attached demo.) Oh well… I guess you could try bookmarks and REF fields instead…

Reply | Quote

I think I must have been unclear in my original post.
Here’s the steps:
1) New doc from template, I need formatted text for superscripts, symbols, etc. in the title, product name, etc.
2) I want that info in properties, so they’re created linked to a bookmark
3) The info may be used elsewhere in the document so the bookmarks will be REF-ed. There’s no need to create more properties to know what bookmarks (whew)

The idea of a data entry section just won’t work: the format of the docs just doesn’t support it well, especially as some of the data is in the header.

The STYLEREF sounds like a good idea, though. I may use that instead of the ordinary REF, to reduce the fragility of the document. That does proliferate the number of styles in the doc, though.

Thanks

Reply | Quote

It’s #2 I didn’t understand. I never noticed that you could create document properties “linked to” bookmarked text in the document. Interesting (although I can’t think of any way I would use it…).

Reply | Quote

It’s #2 I didn’t understand. I never noticed that you could create document properties “linked to” bookmarked text in the document. Interesting (although I can’t think of any way I would use it…).

Reply | Quote

I think I must have been unclear in my original post.
Here’s the steps:
1) New doc from template, I need formatted text for superscripts, symbols, etc. in the title, product name, etc.
2) I want that info in properties, so they’re created linked to a bookmark
3) The info may be used elsewhere in the document so the bookmarks will be REF-ed. There’s no need to create more properties to know what bookmarks (whew)

The idea of a data entry section just won’t work: the format of the docs just doesn’t support it well, especially as some of the data is in the header.

The STYLEREF sounds like a good idea, though. I may use that instead of the ordinary REF, to reduce the fragility of the document. That does proliferate the number of styles in the doc, though.

Thanks

Reply | Quote

Just to make sure I understand this: The user enters some kind of formatted text; you mark it with a Bookmark; you store the name of the bookmark in a Custom Document Property; when you want to cross-reference the original formatted text, you look in the document property to get the name of the Bookmark? Wow. That is going to create support issues for ordinary users.

This is going to sound cheesy, but… in my early days I created “forms” by setting up a data entry section, followed by the document body section. In the data entry section, there was a table, left cell description, right cell data, each data cell with a unique style name. In the document, I used STYLEREF fields to copy the contents of the data table. Users need some training on how to (1) update fields, and (2) use Page Setup with multiple sections (if you target is not plain paper), so there is a little bit of ramp-up you have to do. But it’s quick to edit, you can embed fields within fields in your data table by using STYLEREF fields to import previous data entries, and you can make the document final and presentable by unlinking all fields in the document and deleting the first section.

Now, this obviously isn’t for everyone, but for a quick in-house solution, I think it’s worth trying. When fields are inserted, by default they include the MERGEFORMAT switch, which in theory will coerce any superscript formattting back to the default for the paragraph in which it is being inserted. However, even without the switch, the STYLEREF fields seems to do that. (See attached demo.) Oh well… I guess you could try bookmarks and REF fields instead…

Reply | Quote

Hi Joel:
I like Jefferson’s idea, but if the text that you wish to place in Properties is defined & limited to a reasonable number, you could make each one an Autotext entry formatted in a single custom style & then use the AutoTextList field to pick your entry. I guess you’d still have to bookmark it & use REF fields, so this may not be any better than what you’re doing.

Reply | Quote

Hi Joel:
I like Jefferson’s idea, but if the text that you wish to place in Properties is defined & limited to a reasonable number, you could make each one an Autotext entry formatted in a single custom style & then use the AutoTextList field to pick your entry. I guess you’d still have to bookmark it & use REF fields, so this may not be any better than what you’re doing.

Reply | Quote