Ideas for Designing a Screen with Text entry

[ppbedz]

I have a grid that is used by my department to record information on specific tasks we are working on. The grid consists of a hyperlink to initiate a popup window for inserting a block of text (another grid), a hyperlink for deleting lines, and a text entry field. It is very clunky to work with. The grid looks like is will accommodate more characters than it actually does because of the size difference in characters. The cursor will go to the next line while you are typing, but it does not advance on full words so you have to be constantly aware of what you are typing and go back and correct broken words at the end of lines. Is there a different way to do what I am trying to accomplish? Note: The database file where this information is stored consists of a key and a 70 character text field. Thank you for any suggestions you might have to redesign and make this easier to work with. Patti

[emhill]

In many cases at my shop where a subfile was used to enter text data such as this, I changed the subfile to a text area using a large field and then used the program to parse out the individual records to go into the file. I used the "font family" property of "monospace" and then sized my text area to match the characters I needed in my file (70 characters in your scenario). This might take a little trial and error to get the correct spacing.

The text area will automatically break words for you and place a line feed hex character (hex '25') at the end of a line. You can then scan the large text area field for the LF character and grab everything up to the character to place in your file. You will need to skip the LF hex character when writing to your file. Continue doing this until you have read the entire text area field.

If you are needing to read back from the file and place back into the text area, read one record at a time from your file into the text area field concatenating a LF at the end of each line. This will get the spacing correct when it is re-displayed.

This is really kinda over-simplifying it a tad but hopefully it makes a little sense.

[ppbedz]

Thank you. I will give that a try. - Patti

[Scott Klement]

I agree with the text area approach.

The ideal thing would be to eliminate that "70 character with a key" design and replace it with a single large varchar field (or CLOB field for very large data.) This would be a more modern way of handling "stream data" (which is what this is) vs. forcing into a fixed-length fields that are split across multiple records. But, the multiple records thing will also work if you split things based on linefeeds and carefully fit 70 characters per line in your text area, as Eric has suggested. Often times it's not practical to change the database...

[ppbedz]

I tried a simple example using Eric's suggestion. I ran in debug to examine the results of the scan for the line feed character. The only time I get a line feed is if I manually initiate a line feed to a new line. If I continue to type and let the text wrap, a line feed is not being inserted at the end of the text before it wraps. Am I misunderstanding how this works?

[Scott Klement]

The line feed, essentially, tells you where the user pressed enter. Those should be the only places you find them, NOT where the text wraps automatically.