Preventing Wrapping on Memo field

[penfold1992]

Is there a way I can prevent wrapping in a memo field box?

I have a memo field with a list of email addresses and usernames however the email addresses often just wrap around the end of the memo box just creating a new line in the memo box rather than properly showing the email without the wrapping.

Even if the message scrolls out of the box, id rather that then wrap the text.

Also is there a way in which I can enable someone to open the "ZoomBox" whilst the text box is locked/disabled.

Thanks in advanced

 

[jdraw]

Just curious of the design that would have email addresses and usernames in a memo field rather than atomic fields.

Your set up would suggest you have to parse the memo field for any email/username activity.

 

[penfold1992]

Just curious of the design that would have email addresses and usernames in a memo field rather than atomic fields.

Your set up would suggest you have to parse the memo field for any email/username activity.

the reason is become some will contain 1 or 2 email addresses whilst others may contain 10-20 or even more. Adding 20 boxes when most of the time a user would only need 1-2 isnt a good solution and neither is adding 5 and restricting the user.

so yes the memo field would be parsed but thats not the main concern. the concern is more about how the field shows the data.

 

[jdraw]

the concern is more about how the field shows the data.

Presentation is quite different than storage. Have you considered a table design involving:

tblUser
UserId
other user specific info

tblUserEmail
emailId
userId
email

Such a setup would allow any number of emails per user. You could concatenate email addresses with punctuation as necessary for display purposes.

 

[missinglinq]

This is really a classic one-to-many scenario and should be addressed as suggested by jdraw. For data entry/display, you would use a Main Form/Subform arrangement, with the Main Form based on tblUser and the Main Subform based on tblUserEmail.

Memo Fields work fine when used for their intended purpose, to store narrative type data, but should never be used to store data that will ever need to be searched, sorted, parsed or in any way manipulated. Attempting any of these types of manipulations almost always end up being huge mare's nests, and not worth the effort

Linq ;0)>

 

[penfold1992]

Presentation is quite different than storage. Have you considered a table design involving:

tblUser
UserId
other user specific info

tblUserEmail
emailId
userId
email

Such a setup would allow any number of emails per user. You could concatenate email addresses with punctuation as necessary for display purposes.

but when entering in the data the email would have to be entered one at a time unless you used a complicated method of seperating each email out into a record of its own by using inStr commands to find each email address... and then it would also have to calculate how many records are needed for that string and what if it gets updated? i guess you would have to delete all current records before inserting new records right?