Well, today I made a text viewing program. It doesn't edit, but here's essentially how it works.

A really long string is stored to Str0 with the following format.

"TEXT_FILE_NAME DATE_CREATED AUTHOR_NAME SUMMARY 000000?? TEXT"

The text file name has 16 slots, the date created is in format 09.12.2008, author name has 23 slots, summary has 92 slots and the zeroes are for some features I plan to implement later (section-based navigation, line breaks etc.)

Now what it does is take your spot, X, and do
Text(8,0,sub(Str0,X,23)
Text(14,0,sub(Str0(X+23),23
and so on until it gets to the ending line. 207 letters are rendered at a time (the graph screen's full capacity with full-width letters).

ISSUES: Spaces are only one pixel wide, so lines with spaces aren't filling the screen.

Sorry, but something just came up, I have to go but I'll be back soon.

Back.

Anyway, I'm encountering some problems with the program. Namely, that it sucks.

Issues to be tackled include rendering the text until the end of the line (rather than a flat 23 characters), as the graph font is non-fixed width, as well as the other tokens like sin( that take up 4 characters in text but only come up as one element of the string.

Another issue is the problem of the files themselves. Currently I have ZZTIX001, ZZTIX002, and ZZTIX003, all of which consist of storing the file's contents to Str0 and running PrgmTEXTREAD. This is bad because it takes up a program for every file, the entire a thing can be deleted with a single mis-push of CLEAR, and can't be archived without majorly screwing everything up. Also, it's currently impossible to access really long-a strings (for example if you were to store a book) that would take up the entire RAM. Can't break them in half, there's only 10 strings. A list would be so much better for storing these kinds of things but they can only have 999 elements and they can't store letters.

Finally, the section jumping feature has me vexed. It would be obvious to have a special character (one that wouldn't be used for anything else) represent a section, however I run into problems regarding not rendering this character with the rest of the string (fex displaying %SECTION ONE instead of SECTION ONE where % is the character). And determining which section you're currently at.

EDIT: I've implemented a FIND feature, which is pretty simple and locates occurences of a given string in the file. It can also count the number of occurences of said string in the entire file from any given point. This is nice and all, but the program's still buggy.

EDIT again: The header information isn't intelligently interpreted. Fex, the first N characters will be interpreted as the file name no matter what. And the next M numbers will be interpreted as the author, and so on. One misstep and the whole program could be off. A character to represent "this section is over" would be nice but I'm also having trouble with that.

I expect to be able to upload a beta at some point soon, perhaps you guys could help. Or maybe this is all just way over my head, and I should learn Asm?

Halp!

If this is over your head, assembly is going to be WAY over your head. Can you post up some code excerpts of the offending sections that aren't working properly for us to take a look at?

Well, it's not the programming itself that's over my head, it's the fact that I'm trying to make an application that goes way beyond the limitations of TI-BASIC.

EDIT: It's not that anything's working incorrectly (e.g. in a way other than I would expect it to from my commands), it's just that I can't figure a way around certain roadblocks using TI-BASIC without taking up an obscenely huge amount of memory.

...We've already got DocDE and notfolio, FlameViper. It's unlikely you'll top them in BASIC.

Not to be pessemistic...but a while back I tried the whole "BASIC Text Editor" thing. Mine worked just fine, but it was useless because they do take an exaggerated amount of memory and are not very useful anyway. But if you must do it, then do it.

I don't ridicule it as a project; a text editor is an important way to learn about using string and string functions more efficiently, but it requires some thinking outside the box, as Aeromax noted. For the font-width issue, you can restrict what characters the user can type, assume all characters are 3+1px except for spaces, which are 1 px, periods, which are 1+1px, and commas and parentheses, which are 2+1px.

1.) It's not a waste of effort... all BASIC text editors CAN be pretty sweet =D plus a line-viewer is even easier...


Code:


I would suggest working in the homescreen, at least initially (largely so you can take advantage of the Output command).

Once you have the fundamental code running, you can fairly easily move it to the graphscreen by creating a short loop which will display all the lines, alike Output.

*EDIT*
ugh google Chrome seems to be having some trouble editing text...it fails to clear the remnants of text once portions of the original text have been deleted =([/code]

I have the program here on my computer but I don't see a way to upload files to the topic...?

Post the code, or submit it to the archives as a beta, or Rapidshare it.

Oh, durf. Here it is.


Code:


Here's a simple test file that shows how a header/information work:


Code:

Gah, why do you people always insist on cropping the SC2 copyright text out of the output?

Ok, that code is TOTALLY and kills kittens and puppies.

Omg, seriously.. >.<


Code:



NONONONONONONO, BAD programmer, no cookies for you. Lbls are bad for your health. They can cause bad eye sight, severe migraines, stomach problems, and poor gas mileage.


The loop you are using there is SLOW. The reasoning for this is because everytime you run a Goto, it starts at the top of the program and works its way down til it finds it. Utilize a While loop instead.


Code:


That will speed that up a bit.


And why are you tying up so many Str# variables??!


Code:


Works just fine, and speeds things up because you are not looking to waste that bit of time storing to additional strings, and it saves room. The same things can be applied to the rest of the strings you have up there.

Make the changes to the code, and repost with the new stuff, and we can see where else we can help hack off unwanted coding, etc...

Also, Return is better than Stop is almost all circumstances (especially with shells), so use it instead of Stop.

Actually... I think we need to make the program GO before it will STOP.

But yeah, that is generally a good idea, to use Return instead of Stop.

There are numerous other things, I am sure you can do...

Oh wowzers, I thought using a Lbl was faster than a long block of code.

But yeah, the obscene amount of strings used is mostly because I was doing this entire thing on my calculator (mostly without my notes), so I could just-a-seasily redo it in SC, but I've also got a lot of stuff going on in life, so that'll have to wait until stuff happens.

Nope, I have found a way to use While loops to completely replace Lbl Goto stuff, but still get the same effect while maintaining speed. It is pretty nifty.

I realize that this makes me a total douche, but anyways I wrote a quick text-viewer/scroller thingy utilizing codex to do fast, smooth scrolling...


Code:


1.) This program will scroll/display Str0
2.) "<>" is "not equal to"
3.) R is the line length, while L is the number of lines to display. Adjust at will =D
4.) I'll try to upload a copy of this program somewhere as soon as I can get to my link cable....
5.) Kerm, I haven't been cropping out the SC2 copyright text...I've been typing in this code manually....
6.) Aeromax, you should consider using Celtic2 to store your "text files" in a program rather than in strings...

Very nice, rthprog, good use of Codex. I can tell you're not using SC2 because you have <> instead of the =/= symbol.

thanks Kerm =D


Code:


I just made some minor modifications that fix some bugs (namely the stray pixels when scrolling up) and save some space =D I'm wondering if it would be advantageous to let the user scroll, and update lines once no buttons are being pressed...making scrolling much smoother and a bit faster....

In addition, perhaps storing the image of the lines and overlaying a secondary image which is removed when scrolling would allow such things as sprites, menus, etc...