Editing text box

[kirkm]

If I bind a text box to my table, any text box changes occur immediately in the table.



My problem is VBLF is used, not VBCRLF. So I can't see the text correctly in the text box, but if I alter it, this will also change it in the table.



What might be the best solution? I presume you can't tell access to use just VBLF?

 

[June7]

I tested text with embedded VbLF and access ignores it. Text just runs together. Same with VbCr.

If you are positive text has solo VbLf, use Replace function in textbox expression.

=Replace([fieldname], Chr(10), Chr(13) & Chr(10))

First make sure textbox does not have same name as field.

 

[kirkm]

Unless there's another way, I found I had to use 2 textboxes, one bound and one not and do the replace each way in the On Current event. Otherwise the edit would not be saved in the table ?

 

[theDBguy]

Unless there's another way, I found I had to use 2 textboxes, one bound and one not and do the replace each way in the On Current event. Otherwise the edit would not be saved in the table ?

Hi. Can you post a sample of what you have, so we can see first hand what you're seeing?

 

[June7]

Why is data getting Cr only? You could have one textbox and use its AfterUpdate event to execute the Replace.

 

[kirkm]

It's LF (chr$(10) in the table. Thus it needs changing to CRLF for the textbox to display correctly so you can edit it. (Unless there's some other way... like telling Access what char to use).
Then yes, afterupdate uses replace to save LF only back in the table.

You have a way to do it all with one textbox though ?

 

[Bullschmidt]

I wonder if making the underlying field in the table a Memo field would help.

And/Or

How about in the textbox control change the New Line in Field property from Default to instead be New Line in Field.

 

[June7]

Exactly how is data entered with just LF only?

Setting field as Memo doesn't make difference

However, as Bullschmidt suggested, setting the EnterKeyBehavior property to NewLine should cause a CrLf to save. Will have to tab or click out of control.

 

[kirkm]

>Exactly how is data entered with just LF only?

LOL I guess that's a reasonable question. It's an external data file (non-Access) and is formatted that way.
Yes the enter key behaviour set to newline is right for editing, but it saves a CRLF which is not what we want. A replace at that point with just LF is correct.
I should have made the question clearer, it should be "can an Access text box use LF instead of CRLF". I didn't think so, but who knows what might be possible.

 

[gemma-the-husky]

vbcrlf is a constant, representing chr(13) & chr(10)
is there not a constant vblf, representing just chr(10)

it's probably to do with teletype printers. (and typewriters). You needed a LF to advance to the next line and a CR to return to the carriage to the start. Maybe you don't HAVE to have both.

 

[June7]

I used VBA to concatenate string with solo Cr (Chr13()) and solo Lf (Chr(10)) to enter string into field. In both cases, the code is ignored by Access. Text just runs together. Both must be used in conjunction.

Okay, think I got it. You are using Access to enter data into this other application. Access will enter CrLf with the EnterKeyBehavior property set to NewLine and you want only Lf. I am not aware of any setting in Access to force that.

 

[theDBguy]

I used VBA to concatenate string with solo Cr (Chr13()) and solo Lf (Chr(10)) to enter string into field. In both cases, the code is ignored by Access. Text just runs together. Both must be used in conjunction.

Okay, think I got it. You are using Access to enter data into this other application. Access will enter CrLf with the EnterKeyBehavior property set to NewLine and you want only Lf. I am not aware of any setting in Access to force that.

Hi. Pardon me for jumping in but if this is the case, then one approach I could think of is to use the KeyDown event and trap the Enter key and replace it with Linefeed instead. Just a thought...

 

[June7]

Yes, KeyDown or AfterUpdate - doesn't really matter. Either will save the data as desired but will not display properly in Access. So the idea of two textboxes might be only avenue. One for data input and one for display.

 

[kirkm]

It occurred to me later I could have done a replace vblf with vbcrlf on all the records involved, then reversed that after processing. But 2 text boxes (with the bound one hidden) worked nicely with the Replace in Form_Current, and again in After update.
Thanks for the discussion and that there's isn't a system method for it.