So, based on my own ponderings and the feedback you guys have very helpfully given me in threads here, I've come up with a first draft of a spec for Doors CS-specific libraries for BASIC programs to use. These will of course be available when programs are run from Doors CS or from the homescreen, as long as the Parser Hook (the "Homerun" feature) is enabled. I have so far decided to omit the Associated Program feature for BASIC programs in light of Celtic III's appvar manipulation abilities. I am so far only allowing BASIC programs to call the DCS GUI mouse, but I plan to see what people want with the GUI still, as I have gotten no solid feedback on that account. Notice that a token has not yet been chosen, feedback would be appreciates (stack it in real? use det or identity? use a new token?).

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

(2) 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). -1 if an edge is reached. (dir: 1=up, 2=down, 3=left, 4=right)

(3) 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.

(4) 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.

(5) 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.

(6) 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).

(7) 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)

------

What about GUI stuff though? Don't you guys want some kind of access to multi-line text boxes, password boxes, checkboxes, all that fun stuff? Please add to the above, insult the above, and suggest changes.
I dont see how #5 is going to be useful. It is already possible in BASIC to do "UnArchive Pic1"

You should replace #5 with some window manipulation commands.

EDIT: I think xLib already has this function.
5 might be good for unarchiving an pic whose number is undetermined at runtime.

Also, you could use gcd(, because, honestly, who has ever used it? And gcd( is close to gui, so it might be easier to remember. And anyone who has used gcd(, can you think of a practical application for it inside a program that uses DCS GUI?
I think access to text boxes, check boxes, etc. would be a good thing. It would at least give us the ability to make the programs look like they have a better unified GUI.

As for the token, not gcd because it's a two byte token. How about Menu()? You can, presumably, preserve functionality of the tokens, so it'll still draw menus when it's done the way it's supposed to. It's convenient and in the prgm menu already, and it's easy to remember if you add in the GUI stuff.
That's a good point.
So long as Menu( does not fit the arguments of a DCS command, that would be a good idea.

And GUI would be awesomesauce.
souvik1997 wrote:
I dont see how #5 is going to be useful. It is already possible in BASIC to do "UnArchive Pic1"

You should replace #5 with some window manipulation commands.
Do other people agree? If #5 would only have limited applicability, there's no point in me spending the time programming it.

merthsoft wrote:
I think access to text boxes, check boxes, etc. would be a good thing. It would at least give us the ability to make the programs look like they have a better unified GUI.
OK. Then the next thing to decide is how you want to be able to access it. Would you guys be interested in being able to call an equivalent of PushGUIStack that takes a type number and a string containing hex code representing the item? Is that too hard for BASIC programmers, do I need separate calls for each GUI item? Will you want Doors CS to be able to interact with the GUI you create? In other words, I'm thinking of letting you call the GUIMouse, have Doors CS do all its standard stuff with checking checkboxes or spinning spinners, then at the end return relevant data from the GUI as well as the coordinates of the final click. Would this be good?

Quote:
As for the token, not gcd because it's a two byte token. How about Menu()? You can, presumably, preserve functionality of the tokens, so it'll still draw menus when it's done the way it's supposed to. It's convenient and in the prgm menu already, and it's easy to remember if you add in the GUI stuff.
I suppose I could make it a standard Menu( if the first arg was a string, and try to interpret it as a DCS Menu( command if it's a number?

SirCmpwn wrote:
And GUI would be awesomesauce.
Can you give me more details of how you'd want to be using it?
If we are going to use the Menu( token, why not add a better menu system too?
ti84p wrote:
If we are going to use the Menu( token, why not add a better menu system too?
What did you have in mind?
I think an interesting function that DCS should offer is the ability to return certain data.

Say you want to know the status of prgmTEST

It would kick back size, un/locked, un/archived

Same for Pic and string variables.

That's all I got for the moment..
KermMartian wrote:
ti84p wrote:
If we are going to use the Menu( token, why not add a better menu system too?
What did you have in mind?



One menu could scroll like the Math or Prgm menus but is displayed with the font size used by Text(
and one that uses the mouse and has a scroll bar

For syntax I was thinking it would be more like the regular menu command but with one more parameter at the end:

Code:
:Menu("Menu Heading","Option 1",1,"Option 2",2,1
:"for scrolling menu
:Menu("Menu Heading","Option 1",1,"Option 2",2,2
:"for mouse menu
tifreak8x wrote:
I think an interesting function that DCS should offer is the ability to return certain data.

Say you want to know the status of prgmTEST

It would kick back size, un/locked, un/archived

Same for Pic and string variables.

That's all I got for the moment..
That would be quite straightforward. Perhaps that could replace token(5), if no one has objections? I could make it return a three-element list, where element 1 represents size, element 2 is 0 for unlocked or 1 for locked, and element 3 is 0 for unarchived and 1 for archived. You'd want it to work for Programs, Pics, and Strings? Would other people be interested in this exact form or some variation upon it?
tifreak8x wrote:
I think an interesting function that DCS should offer is the ability to return certain data.

Say you want to know the status of prgmTEST

It would kick back size, un/locked, un/archived

Same for Pic and string variables.

That's all I got for the moment..


DCS7 includes Celtic III/xLib support.
I don't utilize celtic 3 or xlib, never have. I have no idea what they can do. Celtic 2 was supposed to have this ability, but never worked, and Iambian no longer has the source to it.

Also Kerm, would need to have something to kick back with an error if the program doesn't exist for the basic program to use.
SirCmpwn wrote:
DCS7 includes Celtic III/xLib support.
Does one of them have a function to do this? I'm still a bit vague on all the different functions I integrated. Laughing

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

tifreak8x wrote:
Also Kerm, would need to have something to kick back with an error if the program doesn't exist for the basic program to use.
I could return the size as -1, something along those lines?

ti84p wrote:
One menu could scroll like the Math or Prgm menus but is displayed with the font size used by Text(
and one that uses the mouse and has a scroll bar

For syntax I was thinking it would be more like the regular menu command but with one more parameter at the end:


Code:
:Menu("Menu Heading","Option 1",1,"Option 2",2,1
:"for scrolling menu
:Menu("Menu Heading","Option 1",1,"Option 2",2,2
:"for mouse menu
That makes sense, is this something everyone else would be interested? In an ideal world, since I'm dealing with under 4KB at the most for DCSB Libs, including GUI stuff and non-GUI stuff, we'd be able to come up with a Menu( type that everyone liked. I propose that the canonical DCS Menu be a GUISmallWindow with the titlebar of the window as the title of the Menu, numbered options, a scrollbar, and scrolling through the menu using up, down, and enter (with NO mouse). Agree/disagree/think we need multiple types?
KermM, I've been waiting to use GUI in TI Basic for a long time. The only thing that came close was my TI Basic shell that used a full GUI, but that was deleted by my parents DX
This will be truly epic.
I like the idea of a mouse-less menu (ring any KnightOS bells? Wink)

Also, KermM - give me a wiki account and I will document your Celtic III stuff.
SirCmpwn wrote:
KermM, I've been waiting to use GUI in TI Basic for a long time. The only thing that came close was my TI Basic shell that used a full GUI, but that was deleted by my parents DX
This will be truly epic.
Now, the question is whether you're comfortable throwing packed chunks of hex at it, or if you want the calls for GUI setup (equivalent to PushGUIStack) to take more human-readable arguments.

SirCmpwn wrote:
I like the idea of a mouse-less menu (ring any KnightOS bells? Wink)
Only now that you mention it. Very Happy

SirCmpwn wrote:
Also, KermM - give me a wiki account and I will document your Celtic III stuff.
Done! I hope you're able to create an account now.
SirCmpwn wrote:
Also, you could use gcd(, because, honestly, who has ever used it?


I strongly disagree; gcd( can be very useful. Plus, there's no alternative to gcd(, unlike Real(.

You could always try the IS>( and DS<( commands Smile
rthprog wrote:
SirCmpwn wrote:
Also, you could use gcd(, because, honestly, who has ever used it?


I strongly disagree; gcd( can be very useful. Plus, there's no alternative to gcd(, unlike Real(.

You could always try the IS>( and DS<( commands Smile
That's an idea too. So I hear gcd(, IS>(, DS<(, and Menu( as options. No one wants me to tack them onto the end of real( or identity( or det( ?
real(, identity(, and det( are full Razz
KermMartian wrote:
No one wants me to tack them onto the end of real( or identity( or det( ?

I like the idea of keeping it as a separate token, that way the programmer can actually distinguish between Celtic/xLib/DCS commands.

rthprg wrote:
You could always try the IS>( and DS<( commands

I'd be find with those, too, though I still prefer overloading Menu( if only because we'll be making menus with the commands.

KermMartian wrote:
Then the next thing to decide is how you want to be able to access it.

Personally, I'd be ok with either throwing hex at it or having nice function calls. I'd prefer the latter, if only because of ease of use. I feel, though, that a lot of other BASIC programmers don't really want to muck around with hex.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page 1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 1 of 8
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement