I've finally managed to get it to do that, however, it has to generate it then display it. Otherwise, all I get is seizure inducing fun.


Code:

Very nice, tifreak! I just wrote a small extension to that program; try this on for size. It lets you select a color from that chart, and shows a big swatch of the color as well as its number. It switches to a black background for light colors. Sorry for the silly-looking color area; jsTIfied's screenshotter really hated the big palette.

After a bit of integration work, I've gotten Kerm's color table/selector set up stuck into the main program. Here is a shot of it in action:



I still need to program in the ASCII table, and hopefully Kerm can get me the repaired code to display the string data from the appvar. After that, this should be mostly ready for release!

I'd like to ask what you did to get yours to display the boxes live, if I may ask? was it the real(8,1,0? And do we need

:real(0,3,4,255,1
:real(0,3,4,255,1

twice?

An evil trick, in which I set the GRAM being drawn to as the GRAM displayed on the screen. I believe tr1p1ea intended you to always draw to the GRAM not mapped to the screen, then swap the two GRAMs when you finish. Thus the complete screen would appear instantaneously, and you'd be able to start drawing again on the other GRAM buffer. The downside of this is that for something like your program, you'd need to draw the color chart twice, once for each buffer. Yes. That swapped the buffers. At least on jsTIfied, you need to clear both GRAM buffers (which is what that does). It basically does:
(1) Fill the current buffer with white
(2) Swap the two buffers
(3) Now the drawable buffer is the un-initialized one. Fill it with white
(4) Swap back

Sweet, thanks for the info

And I wanted to be sure that wasn't an oops and could be removed.

Now, just need the code for displaying the text string, and I can get that implemented with the ASCII chart.

Unfortunately, it took me 1.5 hours of ASM and BASIC coding to discover what I should have already known: xLIBC uses normal Str tokenization and understands the TI-OS tokens. I think therefore that a chart of ASCII is not necessary for LibHelper, other than mentioning that 47d (ie, "/") makes a good newline character.






Code:

The only reason I was going to put the list up was because it required the number corresponding to the character to know what the new line was, and wanted to give them all the info possible, but there are a lot of characters and values there.

Is there any particular reason why "/" makes a better new line character than anything else?

Because it's often used to represent newlines in things like quotes from poems and excerpts of code posted in IRC, and unless you're trying to display a string that has slashes in it, it's visually pretty clear that those are newlines. Of course, if your string has slashes in it, it would be good to have an alternative.

Then that's just a personal opinion, and I don't think it's worth putting in there that it make a good newline character. It does, but so do ~ and ^ and % and # and | and \. I tend to use ^.

Giving thought to this, I have 1 of 2 choices.

1) Using a setup of <| and |> with the character inbetween, value for character changes based on which character being viewed

2) display all the characters on the screen, create cursor and have the value updated somewhere on the screen, pending what character they are on.

I like idea 2 the best, though 1 would be simplest to implement.

Was just a thought I had while on the routes. Will try to code something of this here afterwhile.

You could gut the code from my map editor:

Kerm pointed me to http://www.asciitable.com/index/asciifull.gif to use for a bulk of them, but that list lacks a lot of the characters in that list. Do we have something that tells us the values of those other characters?

I'm not sure I understand your question. Are you asking what we can type in the TI-BASIC editor to get the different ASCII character in that table? The answer is that there are a lot of those that we can't type. If you do add an ASCII table, I would only bother mentioning decimal 32 through decimal 94, and don't forget that decimal 91 ([) is typed with a theta character. Don't bother with lowercase, because they won't match up, and the rest of the symbols won't match well either.

Oh, okay Thanks for the clarification.

Now, what was it you'd like me to do with the code bits you posted above? Or was it just 'this is what I was doing to see if this worked'?

That was an experiment, based on my assumption that xLIBC did not translate tokens and instead used ASCII. It was really dumb of me to think that, considering that I've displayed lowercase letters using real(6,0 before. That code, while clever and ASM etc etc, is entirely useless for your purposes.

Got this set up now, gives you the values of the character for use with DrawText in xLIBc. You can go left and right to increment/decrement by 1, or up and down to do the same by 10. 2nd/Clear/Enter backs out of it to the main menu.

Next up, generating menus based on the list values I have. After that, it'll be pulling string data from the appvar and displaying.

Looks cool.
This isn't part of the hybrid libs, but could you also include the symbol GUI, but recode it or something similar because it seemed to scroll between numbers incorrectly. It would be a useful part, but considering how big the program/appvar will be...

What do you mean it scrolled through the numbers incorrectly?