Even the TIOS uses the character $0A as a newline; if you display it it draws a ":" then moves the cursor down a row.

Really? That's interesting. I'll take a look at it, wait for the bugfix, and change $FF to \n By the way, I use $FE as a soft return. They can't be the same value. Any good suggestions on what value I should use for that? Not that it really matters much

\n (Line Feed) doesn't mean "return" anyway, it just means "move the cursor down one line". To move it back to column 1 as well, you need \r (Carriage Return) - which is why on Windows you should use CRLF (\r\n), not just \n...

I'm not entirely sure what a "soft return" versus a "hard return" is..?

So, does \r also do something on a calc? Can TASM/Brass compile that to something useful too?

I use two types of returns in my routines, because there's a difference between a newline that a user wishes to have in a string ($FF or the future \n) and newlines that are inserted by the word wrap routine before displaying ($FE). The wrap routine doesn't copy the string, because that would require some safe ram that I don't want to spoil on this. So it changes the given string and adds "soft returns". The next time the wrap routine is called those soft returns are removed first, and then added again (possibly at different locations). If I used the same byte for both hard and soft returns, that step would remove all newlines.

I added about 20 new routines to the API, including some new keyboard routines, draw.square and draw.horizLine (though these still have a bug), string.makeWrap and most of the GUI routines. I didn't do this because they are finished, or because I wanted to show them to anyone, but because I couldn't keep track of them on my harddrive in different files with different notations. So I organized them in the website.

If you find any bugs in the API as a whole, please let me know as soon as possible (the rest of the API shouldn't suffer under my tests), if you find bugs in the new routines I'm probably working on it, but let me know anyway

The API currently has 93 routines and a little under 8000 lines of code in an include file of 144kb

I made a new stable snapshot of the API (now with 66 routines) and added two nifty things to the Latenite Tools package. The first being a project template that makes it even easier to get started with the API and the second being an XML file for the MC AutoUpdater. If I'm not mistaken that makes the API the first project to actually use that thing

In a way, yes But it's probably the most complex and the largest include the Ti scene has ever seen, and you don't NEED Latenite to use it. It's just that I prefer to develop with/for Latenite because it finally gives us a stable, dependable compile environment.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum