So I recently finished the first version of the FileOpen, FileSave, and FileSaveAs routines for the Associated Program (AP) subsystem in Doors CS 6. This gave me the necessary impetus to begin work on Document DE 6. Somehow I completely missed out on Document DE 4 and went straight to Document DE 5; DocDE 5 Beta was released two or three years ago but never got out of beta. I decided to bypass the 5.0 full version and go straight to the 6.0 major number, which coincidentally coincides with Doors CS's version number. So far it's a mere 262 lines; here's what's in those few lines:

We've been waitin...? Oh wait, of course we've been waiting

I never said everyone was waiting for it. But I'm sure you've secretly been eagerly awaiting the day it shall arrive.

any chance of word wrap?

.....and that text....somehow it strikes me as familiar....something about Doors perhaps...no not Doors...maybe those other things that get cut into walls.....and exploring, I seem to remember something about exploring....

That's exactly what I was thinking. I know it might be hard with TI's strange font size, but it looks ridiculous for a word processor to not do it.

I've tried it before; it ends up looking incredibly unideal. IE, you get about 2 or 3 words per a line, all huddled on the left. I'm going to leave it like this for now.

try going newspaper style where inserts spaces between the words

also, I dont think word wrap looks good in the 6*8 font, but its fine in anything smaller, and its hard to read words that cross between lines

Eh, mebbe that will be an improvement for Doors CS 6.1 or 6.2 then. For now I just want to get this textbox working properly as-is.

One more vote for wordwrap - just add it as an option. stop making user decisions for the user

The amount of code required to do this is outside the current scope of my deadline, hence my reluctance. If someone else would like to finish up textinr.asm for me, wordwrap or no wordwrap, I would be quite grateful...

word wrap shouldn't be too much trouble, its a rendering thing, not a storage thing, heck, I did it in basic....when you display the text, instead of just outputting each line, create a lookahead function that tells whether the word overflows the line and output it word by word....

[edit]

even more efficient would be to look every [width of text box in chars] chars. If its not a space, loop backwards till you find a space, dont display it, but instead increment the display line, then begin looking every [width of text box in chars] chars again from that point. If you dont find a space within [width of text box in chars] chars, increment the display line again from the original char. Don't output anything at all if the current line# isn't within the height of the text boxes current scroll setting.

That's not the problem at all, dude. I never said it was a storage problem. The trouble is not finding the pointer location, it's finding the X location of the cursor when you move up a line. It's a total pain, with tons of opportunities for OBOEs.

you could have a section of the appvar that stores the current x location of each displayed line....

I could, but that's an incredibly lame way to do it. I insist on calculating it on-the-fly.

I think not having it at all is much more lame. You can always improve the system in DCS6.x.x.

Nevertheless, I shall complete the current system into full working order before trying this system. Case closed.