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 Razz
Harq wrote:
We've been waitin...? Oh wait, of course we've been waiting Razz
I never said everyone was waiting for it. Smile But I'm sure you've secretly been eagerly awaiting the day it shall arrive.
KermMartian wrote:
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:



any chance of word wrap? Wink

.....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....
elfprince13 wrote:
any chance of word wrap? Wink


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.
KermMartian wrote:
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 Wink

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 Razz
Kllrnohj wrote:
One more vote for wordwrap - just add it as an option. stop making user decisions for the user Razz
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...
KermMartian wrote:
Kllrnohj wrote:
One more vote for wordwrap - just add it as an option. stop making user decisions for the user Razz
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...


Shock 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.
KermMartian wrote:
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.
KermMartian wrote:
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement