Help handling string length overflow?

[wolfesimon]

I have a form where the user copies a handwritten contract into a text
field "Contract1".
The contract usually exeeds 255 characters.
Therefore I provided "Contract2", "Contract3", and "Contract4" fields.
When "Contract1" cannot accept further input, the user continues on to
"Contract2", ect.

I don't want to use memo fields for obvious reasons.

Does anyone have an event procedure and code, which could monitor
typing and programatically move text from the last cariage return to
"Contract2".

Any help sincerely appreciated

[salad]

wo********@comcast.net wrote:

I have a form where the user copies a handwritten contract into a text
field "Contract1".
The contract usually exeeds 255 characters.
Therefore I provided "Contract2", "Contract3", and "Contract4" fields.
When "Contract1" cannot accept further input, the user continues on to
"Contract2", ect.

I don't want to use memo fields for obvious reasons.

Does anyone have an event procedure and code, which could monitor
typing and programatically move text from the last cariage return to
"Contract2".

Any help sincerely appreciated

Well, have you considered making the field a memo field?

This sounds so inefficient tho. Why not scan the contract in to a file
and provide a link to it.

[wolfesimon]

Handwritten contracts.
I don't want to use memo fields for obvious reasons as you point out.

[salad]

wo********@comcast.net wrote:

Handwritten contracts.
I don't want to use memo fields for obvious reasons as you point out.

Oh. I overlooked your statement you don't want to use a memo field.

You could see what the largest contract is. Then create a whole slew of
fields to hold the longest contract. Create an input mask with 255
characters and when the person hits the limit trap the form's OnError
event and go to the next field.

If I had any inclination to do what you are attempting (and I never
would) I would make a separate table with a link to the key and a
contract text field. Now I'd make the contract field(s) a subform with
Cycle set to AllRecords. It would be considered a kludge of major
proportions. Editting the contract would be a major pain in the ass.
It wouldn't automatically reformat if you deleted words or phrases, but
by God it would not use memos and you'd go to the next record if you got
to the end of the field.

[Lyle Fairfield]

I've been using memo fields in Access and X-Base systems now for twenty
years or so and I have missed the obvious reasons for not using them.
What are they?

[Tim Marshall]

salad wrote:

Now I'd make the contract field(s) a subform with
Cycle set to AllRecords. It would be considered a kludge of major
proportions.

As an aside related to this, Banner Finance, an oracle package does
something like this with the stupidest effects. When you want to add
comments to a particular item, you must go to something called document
text which only allows you 50 characters in a field. So if you want to
add a large amount of clarification or whatever, you end up adding
multiple records against the item, each of which is only allowed to hold
up to 50 characters.

I was told by a developer who supports Banner at our organization that
the reason for this was that when the package was originally put
together, fixed space fonts only permitted 50 characters on the
invoice/requisition/purchase order/whatever the heck in the space on the
paper when it was printed.

It's one of the dumbest things I've ever seen, yet, Banner is a very
successful (in terms of sales and implementation) financial package.

It is a nightmare of a GUI anyway, that a 12 year old with a Tandy could
have bettered 20 or more years ago...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[wolfesimon]

I think that maybe I was abiguous in my description.

"Contract1" through "Contract4" are really 1 field on one record and
are already on a subform.
I dont know how cycling through all records would do anything.
"Contract1" should have been named ""Contract Description" here for
clarity.
"Contract2" should have been named ""Contract Description
continuation2" here for clarity.
Etc through "Contract4".
I need code to monitor string length during data entry.
When a sentence reaches the 255 string limit, it would then cut this
last sentence and append it to "Contract2", etc

[salad]

wo********@comcast.net wrote:

I think that maybe I was abiguous in my description.

"Contract1" through "Contract4" are really 1 field on one record and
are already on a subform.
I dont know how cycling through all records would do anything.
"Contract1" should have been named ""Contract Description" here for
clarity.
"Contract2" should have been named ""Contract Description
continuation2" here for clarity.
Etc through "Contract4".
I need code to monitor string length during data entry.
When a sentence reaches the 255 string limit, it would then cut this
last sentence and append it to "Contract2", etc

Me, I'd write a function. I'd store all of the data into the 4
components and then restore to a single entry. I could then grab the
first 255 characters. Since you are interested in sentences, I'd scan
backwards on the first 255 chars and find a period. That'd be desc1.
Then from that positition add the remaining chars to a string. if the
string is over 255 in len, get the next 255 chars and count backwards to
the next period. Continue to complete it. Piece of cake.

I could even then extract the fields from a memo into a query. Call the
function within the query with the parameter 1-4 to determine which line
to return.

[wolfesimon]

I think I can do either of 2 things:

1. Add a memo field to the table.
Then have them type into the memo field.
Then on lost focus, run code to add sentences from the memo field,
until the string variable exeeds 255 length.
Then look back for the period.
Then record the string position X of the period in variable.
Then Record the next string position Y that is not a space.
Then cut the first X number of characters.
Then paste these first X characters into "Contract1"
Then analyze the remainding memo field the same way.
Then paste these first X characters into "Contract"
Etc.

2. Add an unbound field to the form and do the above.

I just don't know if # 2 above would limit me to 255 characters

Question?

If I use the memo field as a type into buffer and then delete its
content, will I avoid the slowdown I would otherwise have by
not using Unicode?

Will the database allocate space for empty memo fields?

Will it require compacting more often?

What do you think

[salad]

wo********@comcast.net wrote:

I think I can do either of 2 things:

1. Add a memo field to the table.
Then have them type into the memo field.
Then on lost focus, run code to add sentences from the memo field,
until the string variable exeeds 255 length.
Then look back for the period.
Then record the string position X of the period in variable.
Then Record the next string position Y that is not a space.
Then cut the first X number of characters.
Then paste these first X characters into "Contract1"
Then analyze the remainding memo field the same way.
Then paste these first X characters into "Contract"
Etc.

2. Add an unbound field to the form and do the above.

I just don't know if # 2 above would limit me to 255 characters

Question?

If I use the memo field as a type into buffer and then delete its
content, will I avoid the slowdown I would otherwise have by
not using Unicode?
In a form, there is no "memo" field if unbound. Basically, all form
objects are variants. If you add a control source that is date, the
type is date, if numeric it is the numeric type, of string, it's string.
But basically, all controls are variants for input if unbound. So I
would not concern myselft with type. If you need 4 fields, concatenate
all 4 fields, input on the string/variant field, and then parse out.
Much cleaner.
Will the database allocate space for empty memo fields?
If unbound, there is no concern.
Will it require compacting more often?
I can't see why. Bloat is bloat. It exists. It gets created. Compact
it. It may or may not occur in this form.
What do you think

To write the function to parse out the data is not complex, nor a
function to extract and return the string value if stored in a field is
not complex.

[david epsom dot com dot au]

No, it's not obvious.

I don't want our sales manager coming in and wacking a couple
of memo fields on every record (they like that), but I can use
a memo field where required.
(david)

<wo********@comcast.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

I have a form where the user copies a handwritten contract into a text
field "Contract1".
The contract usually exeeds 255 characters.
Therefore I provided "Contract2", "Contract3", and "Contract4" fields.
When "Contract1" cannot accept further input, the user continues on to
"Contract2", ect.

I don't want to use memo fields for obvious reasons.

Does anyone have an event procedure and code, which could monitor
typing and programatically move text from the last cariage return to
"Contract2".

Any help sincerely appreciated

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.com> wrote

I've been using memo fields in Access and X-Base systems now for twenty
years or so and I have missed the obvious reasons for not using them.
What are they?

Lyle's question is obvious to me; the reasons for not using memo are not. I,
too, would appreciate knowing.

Aside from some product defects, on rare occasions, that have affected memo
fields, they work "as advertised" and I have had no problems attributable to
using them.

Larry Linson
Microsoft Access MVP