No menu? I guess I am the only one that wants that.

Also, #4 could return positive numbers if a pic is unarchived, and negative if it is archived {1,4,-8} 1 and 4 are unarchived, 8 is archived.

Negative, I would definitely like one too (sorry, I meant to mention this in my previous post).

I say normal functionality
Code:
should be replaced with a DCS window with a scrollable menu. I would very much like a replacement for the default Menu(, that would be awesome

Oh yeah, forgot to mention that one. Would anyone be too depressed if I replaced token(5) with an alias to Menu("Title","Item",Label, etc?

Ooooh, I wonder how that will actually work. I'll need to do some parser tricks to force it to jump to a label. I guess I can return a Goto (Lbl) from my ParserHook, although I'll have to experiment with that more.

If the token is already Menu, then you can just go ahead and overload it, right?

Yeah, I suppose so, but I still want to put something fun and exciting in place for token(5). I'm a tad hesitant to replace the default Menu with a scrollable menu, since that would trash anything that the user had put on the graphscreen, unless I save and restore around the Menu(, which would either use some safeRAM (if I have any left) or mean a bigger memory footprint via saving to a Pic variable.

Ah, ok. In that case don't just overload it. Isn't 5 useful though? Like if it's a pic beyond 9?

I was unaware it was possible to have a Pic beyond 9 (as in Pic 10, Pic 11?).

In any case, I don't see any problem in replacing token(5), personally, as I would have minimal use for it myself.

With all of the XLib and Celtic routines, you can specify any Pic variable between 1 and 255, inclusive; I suppose token(5) would be useful for doing things with them? Can anyone confirm that the TI-OS complains about Archiving or Unarchiving Pics 11 and higher?

I quickly looked at the summary of all commands and it seems pretty nice. It will sure help people programming a lot, and I especially like the mouse routine.

(3) brings me back old memories of Zelda Dark Link Quest programming , as one of the ASM lib used something similar.

Ah, pretty cool! DJ, you're a skilled Hybrid BASIC programmer; do you have anything to recommend? Is there anything missing from the existing BASIC libraries that you wish you were able to do?

The rest of you, Menu( is unfortunately a no-go. It's parsed as if it was a command structure rather than a token, so the arguments are post-parsed, which is a huge headache for me. Does anyone have a second choice for a token?

*bump* Huzzah! I will be using the sum() token. With a list as its first argument, sum() will perform its normal duties. However, if the first argument is a positive integer (which is an illegal data type to the original), then Doors CS will intervene and perform some library function. Of course, that wouldn't be useful as a way of detecting if Doors CS is available, so you can use an extension of the Celtic III detection scheme. Simply use the statement:


Code:


If the TI-OS interprets it, det([[42]]) = 42. If DCS interprets it, det([[42]]) = 1337. If Celtic III interprets it, det([[42]]) = 0. Voila. You could even use this to switch using DCS + Celtic or just Celtic on and off.

Oh, also note that I decremented the number for each routine to start at 0 instead of 1. And a demo!

/me likes the idea.

The detection scheme made me LOL.

hawt. Glad to see a demo, too

And I'm glad you found a token. sum( is a great one to use. I know how frustrating it all was last night, hahah.

Any updates on the implementation of the library functions discussed?

Thanks. I'm working on making sum(6), the SimpleGUIMouse call, but I'm getting frustrated with the TI-OS deciding to hang in an infinite loop when I return a list as the result of the operation. I don't suppose anyone has experience returning a list from a parser hook? I have code examples of real and string returns, but not lists. I can't think what I might be doing wrong.

*bump* First successes with sum(6), which is just about done, pending testing!


Code:


This program will run the mouse, notifying whenever you click, until you right-click somewhere.

That's really cool! That really makes me want to use it, so I just might whip something up using it.

You should, then enter it into the contest. Lots more routines coming soon; I think I'll work on the pixel-scanner one next, since it's relatively easy to write in ASM, but quite useful for things like collision detection.

*bumpity bump* (shush, I'm special, I get to violate the 24-hour rule because I'm excited)

Now sum(0,{string}) is all set. Check out this example program. It's smart enough to deal with just about every character, including many symbols, and can properly handle multi-character tokens like sin( and ANOVA( and T-Test.


Code:

These are really cool

Kerm, out of curiosity, with the menu thing, is it possible to do something to Menu( calls with a MenuHook? Are they processed in the same way as OS menus?

Yes, but in the end I decided not to do that. Actually, that reminds me that I never implemented the planned GUIfied Menu( in the spec on the previous page of this topic, I'll have to add that. At any rate, I'm going to soon post news about this.

Cheers on the complement, elfprince. Did you decide which program you're going to work on for the contest, if any?