Im talking about storing to a label in a program which was a part of my idea of manipulating stack data before pushing

Blah, I meant pushing an immediate. I know you could just do:
whatever
push Ans

but if for whatever reason you want to preserve Ans and push whatever.

I guess the same goes for popping too, though.

is there a way to use labels and vars in inline coding with the Axe parser?(not dcs)

Nono, I understand that completely. I'm confused why SirCmpwn wants to be able to Goto to undefined labels.

Well, since it has to be a token thing, it can be something like token(#,{value}) to push, and token(#+1) to pop to Ans. Therefore, you could put Ans as {value}, but you could equally use 3 or -9.1204 instead, which would leave Ans intact until you popped, right?

Sounds great to me. While you're at it, you could just make lots of stack stuff, like peek, swap, toss (tacos), etc.

That's a good question, I'll ask Quigibo to stop by and tell us.

@ Merth: Well, first I need to figure out where exactly I'm going to be storing this magical stack. Any suggestions, ASM gurus?

Just make it the calc stack. That'll be fun.

Cant you put it in the GUI stack since youll need to make the appvar anyway?

I guess, but that would require a bit of hackery, because the GUI Stack isn't really meant to be used that way. I'm trying to think if there's a piece of SafeRAM somewhere that I could stick it.

what if you used a Custom stack item?Or added the ability to add a blank buffer as type Custom+1 which would be SO useful in a lot of circumstances. That is, unless they're 1 in the same...I don't really use the Custom stack type

Just to add one more thing; copy the DCS homescreen to the graph buffer. That way, Basic programmers can make DCS programs that aren't necessarily full-sized windows. Plus, it would enable us to extend the DCS interface.

Isn't there a way to directly interface with the LCD to copy from the HomeScreen and GraphBuffer to the screen without combining them? Just asking...

Secondly, Can anyone post a list of all the currently listed xLib and Celtic commands used by DoorsCS6.6?

There is, but it would be useless, because then you would write something to one of them, and they wouldn't be combined anymore.

http://dcs.cemetech.net/index.php?title=Third-Party_BASIC_Libraries

I love it! I can't do it with ASM programs, because Doors CS uses the graph buffer as temporary storage while swapping ASM programs to $9d95, but I can totally do it with BASIC programs! Only if run from DCS, though, because HomeRun programs might be expecting to be able to use the graphscreen's contents as drawn or created by the user.

Library idea:
token(#,"command string",expression
so basically at any time the expression is true it will run the commands in the string. while it is false, it will not run them. So it's basically inttereupts I guess. Would this be feasable?

also, token(#,"command string",labelname) and token(#+1,labelname)
subroutines in program

Here's the additions to the spec based on our discussion!

(0) Get string width in var-width font: token(1,{string})
Given a string, find its width if written in variable-width or graphscreen font

(1) Scan for pixel: token(2,{X},{Y},{dir})
From starting location (X,Y), scan along the LCD until an edge or a pixel UNLIKE the value of the starting pixel is encountered (dark to light, or light to dark). If a screen edge is reached, behaves as if the color changed. (dir: 1=up, 2=down, 3=left, 4=right)

(2) Render homescreen on graphscreen: token(3,{update})
Draw 128 characters from the homescreen text buffer to the graph buffer. If update=1, also copy to the LCD.

(3) Used pic vars: token(4)
Returns an N-element list of the numbers of the Pic variables on the calculator (Pic0 = 10). For example, {1,3,10,24} means that Pic 1, Pic 3, Pic 0, and Pic 24 (an extended Pic) are on the calculator.

(4) Arc/Unarc Pic: token(5,{N},{state})
Unarchive Pic N if state=0, or archive it if state=1. If it is already in the desired state, do nothing.

(5) Return DCS Lib Version: token(6)
Will return a number indicating what library is being presented to the program, which should indicate what routines are available. This will be set up to return a specific value when Doors CS is _not_ installed, just like real(0).

(6) DCS Mouse: token(7,{X},{Y})
Run the DCS GUI Mouse starting at {X},{Y}, with acceleration and the user's custom cursor. Will return a list {X,Y,click}, where (X,Y) is the final cursor location, and click = 1 or 2 for left- or right-clicking. This routine will leave the gbuf the way it found it (as well as the GUI stack)

(7) Push GUI Stack: token(8,{type},{more args...}
This will probably be the most complex type. The following {type} values will take the following arguments:
:: 0 :: GUIRNull: {255} is the only argument. If you wish the item to be transparent, use {254} instead.
:: 1 :: GUIRLargeWin: {icon (10 hex chars)},{title string}
:: 2 :: GUIRSmallWin: {top-left X (0-15)},{top-left Y (0-15)}, {icon (10 hex chars)},{titlestring}
:: 3 :: GUIRFullScreenImg: {# of Pic variable containing img}
:: 4 :: GUIRText: {X},{Y},{0},{string}
:: 5 :: GUIRWinButtons: {128 + 64 + 32}. 128 if a minimize button should be shown, 64 if a maximize button should be shown, 32 if a close button should be shown. eg, 160 for just minimize and close. 32 for just close. 64 for just maximize. 192 for all three.
:: 6 :: GUIRWrappedText: {X},{Y},{width in pixels},{0},{string}
:: 7 :: GUIRButtonText: {X},{Y},{string}
:: 8 :: GUIRButtonImg: {X},{Y},{image width in bytes},{button width in pixels},{image hex, 10*image width characters long}
:: 9 :: GUIRTextLineIn: {X},{Y},{width in pixels},{maximum chars},{initial string}
:: 10 :: GUIRRadio: {X},{Y},{group ID},{0 or 1},{string}
:: 11 :: GUIRCheckBox: {X},{Y},{group ID},{0 or 1},{string}
:: 12 :: GUIRByteInt: {X},{Y},{initial},{min},{max}
:: 13 :: GUIRWordInt: {X},{Y},{initial},{min},{max}
:: 14 :: GUIRHotspot: {X},{Y},{width},{height}
:: 15 :: GUIRTextMultiline: {X},{Y},{rows},{px width},{string}
:: 16 :: GUIRSprite: {X},{Y},{height (8 px wide is assumed)},{2*height hex chars}
:: 17 :: GUIRLargeSprite: {X},{Y},{width in bytes},{height in px},{height*width*2 hex chars}
:: 18 :: GUIRPassIn: {X},{Y},{width in px},{max chars},{initial string}
:: 19 :: GUIRScrollVert: {X},{Y},{height in px},{ID},{inc/dec per click}, {min val},{max val},{current}
:: 20 :: GUIRScrollHoriz: {X},{Y},{width in px},{ID},{inc/dec per click}, {min val},{max val},{current}
:: 21 :: GUIRBorder: {X},{Y},{width},{height},{color}
:: 22 :: GUIRRect: {X},{Y},{width},{height},{color}
:: 23 :: THERE IS NO 23
:: 24 :: GUIRMouseCursor: {X1*256+Y1},{X2*256+Y2},{16-char mask},{16-char cursor}

( Pop GUI Stack Items: token(9,{number to pop})
Self-explanatory

(9) Open GUI Stack: token(10)
Initialize it

(10) Close GUI Stack: token(11)
Shut it down

(11) Render GUI Stack: token(12)
Just render, don't call the mouse

(12) GUIMouse: token(13)
Render, and start the mouse. This will return a whole mass of stuff, including a list of {X,Y,num}, where num is the index of the element that made mouse execution stop, and a String (maybe Str0?) that contains packed outputs from text input boxes, number input boxes, radio buttons, and checkboxes.
How does that strike you?

Looking good!

Would it be practical for Basic programs to access DCS' filesystem? As in, could we find what folder a program is in, move programs, rename/create/delete folders and what not?

Right now, moving lots of programs around is a bit of a pain (no offense), and I would love to be able to just write a program that could do the heavy lifting for me

rthprog, it wouldn't be too practical at this point. However, I am strongly considering making an ASM program that uses the DCS GUI that allows you to see a list of programs in each folder, put checkboxes next to a bunch of them, and then choose to move them to a specific folder. I think that would cover the request you're making here.

I like it!

Of course, it would be very nice if the program was granted access to these functions by the user. For instance, maybe have an interrupt when the program executes a DCS filesystem-based function and draw a permissions dialog box? If the user chooses Yes, then the program continues executing, if the user choose No either (1) exit the program, or (2) return the permission data to the program so the program itself can either exit or continue execution.

The permissions should also be granted either for the current session, forever (with the option to change later), never, or not for the current session.

Too much?
EDIT I guess you answered that question with the post above



Also, I will definitely be taking advantage of 1, 2, and 7. I'm quite a big fan of 7 atm honestly

Another concern I have about the file manipulation routines is that it would lead to masses of poor BASIC shells based on the DCSB Libs.

Glad to hear that you're a fan of (7); hopefully you'll also be suitably happy with the more complex GUI stack routines once you get your hands on them.

Definitely, I probably will enjoy the other GUI stack routines, once I get familiar with them

Not familiar with ASM completely yet, but I'm quite excited about the current list