PDA

View Full Version : Insert text from external file into Word 03 Formfield



mikemc
02-21-2008, 04:35 AM
I've created a template using Word 2003 with multiple form fields which is protected. I need to find a way for a text form field to populate with information from an external text file based on what the user inputs into the form field.

Example:
In a text form field, the user types a code [which refers to information stored in the external text file located in a certain directory on the hard drive]. Say the user types in "#i-a-1", the VBA code would recognize the input and then place the correlating paragraph of text from the external file into the form field.

At times, a user might need to put more than one code into the form field, i.e. '#i-a-1' and '#i-a-2'.

This is similar to the autotext function, but [as you know] autotext doesn't work when the file is protected for form fields.

Any help on this is greatly appreciated!

Mike

Tinbendr
02-21-2008, 08:17 AM
...which refers to information stored in the external text file located in a certain directory on the hard driveWhat kind of file? Another Word file? What is the format of the external file. Paragraphs or table?


but [as you know] autotext doesn't work when the file is protected for form fields.
Autocorrect will work with formfields. You still have to type a space after the code to make it activate.

fumei
02-21-2008, 10:26 AM
1. AutoText most certainly CAN be used with formfields in a protected document. The thing is, they replace the formfield. Say you have:

Autotext entry "yad" that is the text: "This is the Yadda sentence."

A formfield named "Text1"

The document is protected for forms.

ActiveDocument.AttachedTemplate.AutoTextEntries("yad") _
.Insert _
Where:=ActiveDocument.FormFields("Text1").Range, _
RichText:=True
will replace the formfield "Text1", with the AutoText entry "yad" - i.e. "This is the Yadda sentence."

The formfield will no longer exist. Its range becomes the AutoText.

2. Tinbendr is correct. AutoCorrect will work IN the formfield.

AutoCorrect and AutoText are separate objects (Collections). Separate. Therefore, they can even have the same name.

AutoCorrect name "yad" = "NEW! NEW! NEW!"
AutoText name "yad" = "This is the Yadda sentence."

In a document, type: "yad"

1. "yad " - yad plus spacebar (AutoCorrect)
"NEW! NEW! NEW!"

2. "yad" + F3 (NO space!) is AutoText
"This is the Yadda sentence."

In a formfield, as "yad " - yad with a space - is TEXT, therefore AutoCorrect functions, and you get the AutoCorrect entry.

True, in a formfield "yad" + F3 (AutoText) does not work in the GUI. However, you CAN insert an AutoText entry into the formfield range via code.

Again, though, it replaces the formfield with the contents of the AutoText.

Just working through the logic here.....I know, my favourite rant, but hey, ya gotta do what ya gotta do.

Replacing the formfield may not be what you want to do. So, now what.

An AutoText has a value. Hmmmmmmmmm.

Say you have two AutoText - not AutoCorrect.

AutoText name "yad" = "NEW! NEW! NEW!"
AutoText name "yad2" = "This is the Yadda sentence."

The values are strings....so....you can make a string variable containing BOTH of them, like this:
Dim Both As String
Both = ActiveDocument.AttachedTemplate.AutoTextEntries("yad") _
.Value & " " & _
ActiveDocument.AttachedTemplate.AutoTextEntries("yad2") _
.Value
ActiveDocument.FormFields("Text1").Result _
= Both
The formfield .Result will indeed be both of the AutoText entries, AND the formfield is not removed. You are simply putting in the .Result you want.

Now, to the actual problem/issue. Here is the solution. You can use this, or a version as the OnExit macro of the formfield.

Dim StrIn As String
Dim Both As String
StrIn = ActiveDocument.FormFields("Text1").Result
Select Case StrIn
Case "i-a-1"
ActiveDocument.FormFields("Text1").Result = _
ActiveDocument.AttachedTemplate.AutoTextEntries("yad") _
.Value
Case "i-a-2"
ActiveDocument.FormFields("Text1").Result = _
ActiveDocument.AttachedTemplate.AutoTextEntries("yad2") _
.Value
Case "i-a-1 i-a-2"
Both = ActiveDocument.AttachedTemplate.AutoTextEntries("yad") _
.Value & " " & _
ActiveDocument.AttachedTemplate.AutoTextEntries("yad2") _
.Value
ActiveDocument.FormFields("Text1").Result _
= Both
Case Else
' other logic?????
End Select


So, to finally get to the point.....

If the user types in "i-a-1", the Autotext "yad" is inserted into the formield, and formfield is NOT removed.

If the user types in "i-a-2", the Autotext "yad2" is inserted into the formield, and formfield is NOT removed.

If the user types in "i-a-1 i-a-2" - i.e. both! - , the Autotext "yad" AND "yad2" are inserted into the formield, and it is NOT removed.

As you can see, the coding is not difficult at all. The logic is where the weight is.

"At times, a user might need to put more than one code into the form field, i.e. '#i-a-1' and '#i-a-2'."

While the code above can handle this - or any other string combination really - I am not sure this is all that great of a design. Getting multiple separate identifiers (i.e. "i-a-1" and "i-a-2") out of one string is certainly possible, but again, there may be a better design.

What is the purpose, the logic?

To get a user entered string, and insert text into a specific location.

In any case, yes, you can get an AutoText entry into a formfield, including multiples.

mikemc
02-21-2008, 11:00 AM
I think you're onto something with the code, but I agree there might be a somewhat better design, especially due to the amount of coding I'd have to do with my particular project.

One issue that must be overcome is that I've got multiple text formfields [Text1 through Text100+] and I've got approximately 300 different possible 'autotext' entries [each with their own identifier]. That would be a serious undertaking coding all the possible formfield names along with all the possible autotext entries.

That's why I came up with the idea of each text entry residing in its own .txt file and having the template call in the entry based on the string input by the user. I don't know if I'm on the right track with that or way off base?

fumei
02-21-2008, 11:13 AM
Off base.

1.. If you are going to do that, why on earth would you put them into separate (100 + !!!!) .txt files? Ai carumba! You can put them into one file. MUCH MUCH easier to maintain.

Ai carumba #2!
"One issue that must be overcome is that I've got multiple text formfields [Text1 through Text100+] and I've got approximately 300 different possible 'autotext' entries [each with their own identifier]. That would be a serious undertaking coding all the possible formfield names along with all the possible autotext entries."

My bolding.

If this is a problem/issue, then you are going to have to explain in better detail.

Are you saying that for ANY text formfield (text1.....text100), you can have up to 300 possible actual chunks of text that will actually be put into the formfield????

If that really is your situation, then I will categorically state....rethink your design. That is crazy.

I am not saying it is crazy that there can many possibilities of text that need to go to a specific location. That is a common of requirement. I will say that it is crazy to do that via multiple text files inserted into formfields.

I bolded in your quote to reiterate that this is NOT a coding issue. This is a logic issue.

Again.

mikemc
02-21-2008, 11:40 AM
fumei, you are right on track with the 'ai carumbas' !

Yes, with each textbox, there could be up to 300 (or so) possibile chucks of text that the user might need to input. Most of the time, only 3-5 might acually need to be put in, but would need the ability to choose from any of the chunks.

This is a real estate home inspection report, so the user needs the ability to choose from the 300 or so 'defects' and the 'defects' should be available for all the different textboxes.

I'm open to rethinking the design, but I've been trying to wrap my head around this whole thing and, apparently, in need of another's perspective. Thanks a ton!

Mike

fumei
02-21-2008, 11:50 AM
Think!

What is the real purpose, and logic? Spell it out. Write it out. You. Take a piece of paper - I know that seems so passe, but it works better - and, write it out.

WHY are you stuck on text formfields?

HOW does the user select from those 300 possible choices? Are you saying it is done by them typing strings?

"#i-a-1"
"#y-p-23"

yadda yadda

Are you trying to convince me that your users have 300 chunks - as cryptic codes like "i-a-1" - memorized????

I find that rather incredulous.