sk5t
asked on
Designing a "correspondence" table
I'm contemplating how to build a growable "table" of protected correspondence into a form, in R4.5.
The general idea is to present the user with an area for entering data, preferably (but not necessarily) in a rich text field, with a way of protecting the data as author permissions pass on to other users, etc. It is not necessary to automate that protection with form events or anything else... users will press a button to "add and protect" the information when they're satisfied.
I built a solution using a static-sized table, with button-driven hide formulas in conjunction with editable and computed fields, but it isn't dynamic enough--coding the rows is somewhat laborious, and ten rows are probably not enough.
A simple table with one field per column might work, if there's a way to vertically align the "heading" information captured in one cell with the "body" in another--keeping in mind the "body" is likely to be many lines longer than the heading, but of course we can't calculate how many lines longer when actually displayed... perhaps some method of adding rows to a table?
Thoughts? I hope I'm being clear, this is a tricky one to explain.
The general idea is to present the user with an area for entering data, preferably (but not necessarily) in a rich text field, with a way of protecting the data as author permissions pass on to other users, etc. It is not necessary to automate that protection with form events or anything else... users will press a button to "add and protect" the information when they're satisfied.
I built a solution using a static-sized table, with button-driven hide formulas in conjunction with editable and computed fields, but it isn't dynamic enough--coding the rows is somewhat laborious, and ten rows are probably not enough.
A simple table with one field per column might work, if there's a way to vertically align the "heading" information captured in one cell with the "body" in another--keeping in mind the "body" is likely to be many lines longer than the heading, but of course we can't calculate how many lines longer when actually displayed... perhaps some method of adding rows to a table?
Thoughts? I hope I'm being clear, this is a tricky one to explain.
ASKER
Hi,
I appreciate your input, but (oh bother!) enforcing 'hard' limits on the field length with a fixed-width font in layout regions won't satisfy design requirements. Users are going to want to bold/highlight/color their text, use file attachments, etc.
So, it looks like I'll end up going for one RT field for input and another computed, "safe" field to contain the history, using the AppendRTItem Script method. With any luck, eye-friendly indentation and formatting will do the trick...
Points if you (or anyone) can provide a LScript code snippet to append one richtext field to another, on a button click, and have it show up in the frontend. :-)
I appreciate your input, but (oh bother!) enforcing 'hard' limits on the field length with a fixed-width font in layout regions won't satisfy design requirements. Users are going to want to bold/highlight/color their text, use file attachments, etc.
So, it looks like I'll end up going for one RT field for input and another computed, "safe" field to contain the history, using the AppendRTItem Script method. With any luck, eye-friendly indentation and formatting will do the trick...
Points if you (or anyone) can provide a LScript code snippet to append one richtext field to another, on a button click, and have it show up in the frontend. :-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That'd be great -- feel free to fire off a copy to stv@ot.com ...
I thought about doing it with response/child documents, but would rather keep everything on one page for "one-shot" request tracking. (The contents of this database will probably be turned into hardcopy quite a bit.) Although it is entirely possible that's the more elegant way to do it, and the correct implementation eludes me.
Thanks!
Steve
I thought about doing it with response/child documents, but would rather keep everything on one page for "one-shot" request tracking. (The contents of this database will probably be turned into hardcopy quite a bit.) Although it is entirely possible that's the more elegant way to do it, and the correct implementation eludes me.
Thanks!
Steve
ASKER
That'd be great -- feel free to fire off a copy to stv@ot.com ...
I thought about doing it with response/child documents, but would rather keep everything on one page for "one-shot" request tracking. (The contents of this database will probably be turned into hardcopy quite a bit.) Although it is entirely possible that's the more elegant way to do it, and the correct implementation eludes me.
Thanks!
Steve
I thought about doing it with response/child documents, but would rather keep everything on one page for "one-shot" request tracking. (The contents of this database will probably be turned into hardcopy quite a bit.) Although it is entirely possible that's the more elegant way to do it, and the correct implementation eludes me.
Thanks!
Steve
Via Notes, it will be difficult to line up each item with its corresponding data in other columns. Using more than one document with an embedded view to display would be appropriate.
However, my recommendation is to use a web interface, where this problem can be resolved.
Via the Web, here's the answer:
Two parts to this solution:
1.Build the fields to hold the data for each column. As an example, for 3 columns, make 3 fields: ("Field1", "Field2", "Field3"), computed based off their own field names. You would also have three editable input fields (Input1, Input2, Input3).
Finally, an add button would have code along the lines of:
FIELD field1 := field1:input1;
FIELD field2 := field2:input2;
FIELD field3 := field3:input3;
@Command([FileSave]);
@Command([ReloadWindow]);
(Assuming you are using R5, where reload window is valid.)
2. To make these fields diplay in a table where the values from each field are appropriately lined up with each other, use HTML.
Your HTML would look something like this:
"<table><tr>" +
"<td><table><tr><td>" + Field1 + "</td></tr></table></td>" +
"<td><table><tr><td>" + Field2 + "</td></tr></table></td>" +
"<td><table><tr><td>" + Field3 + "</td></tr></table></td>" +
"</tr></table>"
Because @formulas acts as a loop on text lists, this will build you a table with a row for each set of values in the fields. Because the tables are embedded within each other, the data should line up appropriately.
Note: Rich text will not work with this method. Numbers or text work great, and dates work if you wrap @Text() around the field name in the HTML.
However, my recommendation is to use a web interface, where this problem can be resolved.
Via the Web, here's the answer:
Two parts to this solution:
1.Build the fields to hold the data for each column. As an example, for 3 columns, make 3 fields: ("Field1", "Field2", "Field3"), computed based off their own field names. You would also have three editable input fields (Input1, Input2, Input3).
Finally, an add button would have code along the lines of:
FIELD field1 := field1:input1;
FIELD field2 := field2:input2;
FIELD field3 := field3:input3;
@Command([FileSave]);
@Command([ReloadWindow]);
(Assuming you are using R5, where reload window is valid.)
2. To make these fields diplay in a table where the values from each field are appropriately lined up with each other, use HTML.
Your HTML would look something like this:
"<table><tr>" +
"<td><table><tr><td>" + Field1 + "</td></tr></table></td>" +
"<td><table><tr><td>" + Field2 + "</td></tr></table></td>" +
"<td><table><tr><td>" + Field3 + "</td></tr></table></td>" +
"</tr></table>"
Because @formulas acts as a loop on text lists, this will build you a table with a row for each set of values in the fields. Because the tables are embedded within each other, the data should line up appropriately.
Note: Rich text will not work with this method. Numbers or text work great, and dates work if you wrap @Text() around the field name in the HTML.
ASKER
I hate to be a bad guy, but:
- It's gotta be R4.5 for now, as I stated in the initial question
- (although I didn't really specify) it's through the Notes client, not a browser--so no embedded views or HTML, alas. The ability to add attachments and formatting is too important to axe.
At this point there may be no way around using .AppendRTItem on the backend... this would mean scrapping the table idea, but 'vertically' formatted labels are viable.
- It's gotta be R4.5 for now, as I stated in the initial question
- (although I didn't really specify) it's through the Notes client, not a browser--so no embedded views or HTML, alas. The ability to add attachments and formatting is too important to axe.
At this point there may be no way around using .AppendRTItem on the backend... this would mean scrapping the table idea, but 'vertically' formatted labels are viable.
I sent you the dynamic table example, you got it ?
ASKER
Yes, thanks for the file. However, unless I am missing something, it works strictly on list manipulation within a fixed number of columns (one field each), and the display gets messy if any single chunk of data breaks to the next line. As such it can't really be used for capturing correspondence, nor rich text items. Do you agree?
ASKER
Yes, thanks for the file. However, unless I am missing something, it works strictly on list manipulation within a fixed number of columns (one field each), and the display gets messy if any single chunk of data breaks to the next line. As such it can't really be used for capturing correspondence, nor rich text items. Do you agree?
I had a similar dillema, and
there is no good way of doing it
you must assume a certain character length and deal with it.
I know it sucks, but it's true.
Only option that may be usefull ,depending on platform variety in your company, is to write to an excel spreadsheet and reattache it everytime you get an entry. But that's a pain.
there is no good way of doing it
you must assume a certain character length and deal with it.
I know it sucks, but it's true.
Only option that may be usefull ,depending on platform variety in your company, is to write to an excel spreadsheet and reattache it everytime you get an entry. But that's a pain.
ASKER
Adding to my frustration, it looks like the .appendRTitem method just plain makes a mess of things in R4.5. Oh sure, it'll add one rich text item to another, but try it a second time (after closing and reopening the document of course) and it removes all the spaces and linebreaks! Not good.
(Here's looking forward to R5... I think...)
(Here's looking forward to R5... I think...)
ASKER
I guess this one is just unanswerable. Closing it out, just to get it off my list... assigning points to Paedbd for effort.
ASKER
(Rich text fields are evil.)
Basically an unanswerable question... away it goes.
Basically an unanswerable question... away it goes.
I don't feel that you can block access to the other users on a single field, multi part data. But you can format the field to simulate the dynamic list/table. For this there are few simple steps involved.
1. Create the table to have the necessary RT field.
2. Set the Font to Courier 10.
3. Whenever the user clicks add button, Use the Subform with layout as the input.In that layout use a field with fixed width and height( sufficient enough to hold the max possible data). This field should also be of Courier 10.
4. You may have to do trial & error basis appending because once you find the exact layout field width to dump the data as is in the RT field.
Hope this explains how to proceed. If not contact me at hemanthakumark@bigfoot.com
Good Luck
~Hemanth