Odd formfield behaviour

[vjrs]

I have a template that contains several formfields; the important ones for this behaviour are the textfields, which are updated by calling an instance of a text-input userform via the formfield's 'on entry' macro call.

The user types into the textbox on the user form, and the intention is that pressing 'Enter' will produce a paragraph (multiline to TRUE and enter behaviour to TRUE enables this). However, when the text box contents is used to update the formfield, the formfield displays two boxes where the end-of-line should be:
ABC
DEF
typed into the textbox gets mutated to
ABC□□DEF (the squares are full height in fact).

From my investigations, these two square characters correspond to the single character: chr(13). In the input-text box, the chr(13) is followed by a linefeed, chr(10), but this disappears when the formfield is populated (and its presence doesn't seem to be necessary).

To make matters more frustrating, I have a similar 'cut-down' document in which the text-input (text-box on a user form) and output (the formfield) behaves as expected - as a newline, suggesting a paragraph (which is exactly what I want). Comparing the ascii codes produced by the two word documents at each stage doesn't reveal any differences between them, leading me to wonder if there is some formfield property that has changed. I can find no reference to this behaviour in the documentation or on the web.

Any ideas anyone? I would be extremely grateful for some guidance.

I am using Word 2003 (Office Professional) SP3 on Windows XP Pro.

[lucas]

Have you tried using bookmarks instead of formfields?

[fumei]

You just have to to fiddle with Replace and keep testing until you get the correct effect. I just did a test and tyhe Chr(10) made it into the formfield, and the vbCrLf (the odd "double-character" of a paragraph mark - Chr(13) & Chr(7)) is handled correctly. In which case the foiltering is done afer the fact.

I have no idea why these things get handled strangely by Word.

And yes, using a bookmark could very well be a viable alternative. in fact, if the result is NOT to be edited/changed by the user then using a bookmark if preferable. Formfields are meant to be used by users. That is their point. If you are not using that way...why use them?

[vjrs]

Thanks both. The point is that the formfield is supposed to be updated by the user. The reason I'm using a separate form is because (I have read somewhere) it is supposed to be preferable.

Thanks again.

[fumei]

"The reason I'm using a separate form is because (I have read somewhere) it is supposed to be preferable."

Why on earth would that be?????

[vjrs]

Well... because I've read it somewhere and I am less experienced in this than the source of my advice; but I am open-minded and happy to be guided by the better informed.

[Paul_Hossler]

The reason I'm using a separate form is because (I have read somewhere) it is supposed to be preferable.


<Humble Opinion Mode = On\>

In Excel, a lot of times a User Form is easier to understand that a lot of controls sprinkled all over the worksheet since it keeps the UI 'in one place'

In Word, Form Fields (or Content Controls in 2007) seem to work better since the 'sheet of paper' paradigm seems to bound the user's attention

<Humble Opinion Mode = Off \>

Paul

[lucas]

That's fine Paul if everyone is more comfortable with that, but the poster stated in his first post that he was using a userform....

[Tinbendr]

I've had the exact same problem before. I never found a solution, but the problem is not new. See this (http://groups.google.com/group/microsoft.public.word.vba.general/browse_thread/thread/80cc4c71b53c48c8/dec14513bebf0474?hl=en&lnk=gst&q=two+small+boxes#dec14513bebf0474).

You might try this. (Only a guess.)

'Workaround for when RFR description is over 256 characters
With OADoc
If Len(RFS1$ & RFS2$) > 255 Then
Application.StatusBar = "RFS workaround"
If .ProtectionType <> wdNoProtection Then
.Unprotect
.Refer to the fields() instead of just .Result.
.FormFields(BRFR%).Range.Fields(1).Result.Text = _
UCase(RFS1$ + RFS2$)
.Protect Password:="", _
NoReset:=True, Type:=wdAllowOnlyFormFields
End If
Else
'oadoc.FormFields(BRFR%).Result = BuildRFS
OADoc.FormFields(BRFR%).Result = UCase(RFS1$ + RFS2$)
End If
End With

Then use .fields.update to refresh the formfield.

My problem went away when we went from W97 to Word 2003.

Good luck.

[Paul_Hossler]

lucas -- yes he did say he was using a UserForm, but later "The reason I'm using a separate form is because (I have read somewhere) it is supposed to be preferable."

I was thinking that a UserForm (like anything else) might be a good solution sometimes, and not others, i.e Preferable in Excel, but not preferred in Word where Form Fields might be more effective

Paul

[fumei]

I think it may be helpful if we understood EXACTLY what is needed.

If the object is to have user enter data (text), then if it is a straightforward input, then a formfield by itself should be fine. I see no need for a userform. That being said, I am a fan of userforms...but only when that is what makes things easier.

In this case, does it? Yoy have a userform that the user enters text into; then there has to be something that closes the userform, and that input placed into a formfield...that can then ALSO be changed.

Hmmmmmmmmm. That does not sounds particularly easier.

[vjrs]

Thanks Gerry. Well, yes, I think it does make sense to use a userform.

The purpose of the template is to allow inexperienced users to complete a notification of a significant event within a business; it is useful to have other buttons on the form, for example 'guidelines' to allow access to extra help should the user need it. Now it may be that this could be implemented without forms, but a userform titled 'Details of the Significant Event' does focus attention on what actually happened, and I think will enhance the quality of the reports and notifications we get.

So that's the reasoning.

Viv

[fumei]

Sounds reasonable to me. However.....it still has the result of getting input from a user, who can then change the input into whatever they want.

[vjrs]

Not sure I get this - do you mean that the formfield appearance could be changed subsequently the user if he/she wanted paragraphs?

[fumei]

Yes. It is just a formfield, and therefore all attributes and capabilities of a formfield apply.

However, the point I was trying tp make is that you are making effort to get - say - an input (via the userform) of "Yadda".

OK, you get "Yadda" from the userform, and place "Yadda" into the formfield.

The user can change this to "What on earth was I thbnking, HECK< I can not evenspell, or make gramatical eerorrrrs without that darn martini at lunch coming bqack to haunt me."

BOTH - as it stands - are equally valid content.

Therefore, if the user to change was is in the formfield (and they can) what exactly is the point of the userform? It is not like it is being used to control content. There is no validation being performed.

I still would like to reiterate that I love userforms, and believe that they are a very good way to gather user input. Often, they are the better way. In fact, it is possible to gather data from a userform and place that into a document where the user can NOT change it.

[lynnnow]

Just my two cents,

We had a similar setup to input a patient's demographic details onto a template. The body of the report had to be manually transcribed, but it did not interfere with the demographics section. The demographics data should not be touched after the user input the details on a userform. The userform used bookmarks to locate the position for input, however, if the user had a problem while entering the data in the userform, they could manually go and replace the text in the demographics section, which led to deletion of the bookmark at that location.

The setup we currently use is a formfield on a protected document, so that even if edits have to be made, it is done manually, without using a userform to collate data.

[vjrs]

There's food for thought here, and I think that I can complete the programming task, now. Thanks all of you for your help.

I remain, however, curious as to why the problem exists in one VBA project, but not in another, very similar, one.