I've long since considered that it would be awesome to have some way for BASIC programs to use Doors CS's libraries, especially the GUI ones, considering all the nifty functionality that thinks like XLib, PicArc, Omnicalc, and Celtic enable. Up until now, I've never seriously wanted to actually implement such a thing, as I was concerned about breaking compatibility both for past versions of Doors CS, but with the introduction of full Celtic III support (plus plenty of bug fixes), I'm beginning to consider how I could add DCS GUI and possibly more support for BASIC programs. I'd have to choose a token, probably det() since real() and identity() are both overused, and more importantly, I'd have to think of a mechanism. The easiest thing I've thought of is something where the BASIC program would package up basically a GUI Stack into binary and pass it in Doors CS. Doors would render it, and return control, or in another routine, render it and then activate the mouse, returning either a chunk of data containing the stack once it finished, along with either coordinates or an index of the item clicked that stopped mouse activity. As you can see, I'm still very vague on the mechanism, so I need feedback. If you were a BASIC programmer and you were writing Doors CS programs, what features would you like access to? The GUI? The AP system? Other things? Of course, right now I have about 2KB to work with, so it should initially be something simple for me to implement, and hopefully I can optimize down my and Iambian's code and make more room to bring this to fruition, if it sounds like something people are interested in.

Hmm, being able to open a window and use text boxes and such would be nice. I can't really think of too many applications I could use DCS stuff though, without being an asm programmer and making things specific to DCS.

Personally I think access to the GUI stuff would be best. Being able to define a window area and a text string and some buttons would and stuff like that.

Fair enough. Would you want to be merely able to tell Doors CS things to render and have it render them? Or would you also want to be able to invoke the mouse? Would you also want to be able to use any other DCS-specific vectors, like Runprog, for instance?

Excellent, that sounds like the concensus. Again, would you want to be merely able to tell Doors CS things to render and have it render them? Or would you also want to be able to invoke the mouse?

I think it would be great to invoke the mouse. I'm personally unsure how libraries work, so I'm not sure what the code would look like (or what it can look like).


EDIT: Like I mentioned in the other thread, maybe overwrite Menu( if a parameter is set in the DCS header?

If so, maybe something like
Menu(window_title,return_lbl,item1_type,item1,item1_return,[item2...]

Something like this would be massively massive, so I'm definitely not sure about the syntax because honestly I think it's just unbearable, but I came up with it on the spot.

window_title = The window title, of course
return_lbl = Label if the user presses the X in the top right
item#_type = numerical: 0=menu item,1=text input,2=button
item# = text displayed
[i]item#_return[i] = if *_type=0|2 then it will jump to the label specified. if *_type=1 then it will store the data in the variable specified.

Yeah... I don't freaking know... I'm sure there's plenty of good ideas that will be generated in the very near future.

Cool! Even if not something to retain in the final version, this is definitely a good starting point in terms of ideas! I particularly like that your idea doesn't simply make a GUI translation of a TI-OS-style menu, in that it also offers text input and buttons. I think I would also like to expand this with at least checkboxes if this is the type of syntax I eventually decided upon. TI-89 / 92 / V200 users like tifreak8x, can you perchance give me some guidance on what those models do with GUIs and interface boxes, and if any of that is translatable?

Definitely would like checkbox support

This might be useful to you, as it pertains to TI-89's Menu( function.Source: http://ti86world.tripod.com/programming/chapter04.htm

TI-86, you mean? Still a good point, though. I think I'd ideally like to use more than the bottom of the screen though. Hmm, idea, if I did this, I should probably use the first argument of Menu( to specify whether it is a large window, small window, or invisible window, no?

I you implement mouse control, give control to the TIB programmer; for example, if I click a checkbox, don't have DCS "check" the box, let MY code do that.

All I would need would be rendering routines, and a way (like real(14) for xLib ) to check if an applicable version of DCS is installed (and if not, allow my code to display a message and quit)

Oh, really? So if a checkbox was clicked, return to the BASIC code and tell you about it, and then let you choose to modify the data passed to make it a checked checkbox, and rerender and re-mouse?

Indeed, I'll probably implement some form of the real(0) trick.

Just providing scrolling menus would be extremely useful.

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:

I think that's a bad call unless you plan to make custom check boxes. If not DCS should return a list (in the order of the boxes) of what boxes were checked, such as {0, 1, 1, 0, 1, ...} for boxes 2, 3 & 5.

Or, or, or!!! Take input from a matrix, and how that matrix is created, is how the items are displayed. The user creates a matrix in [A] and it could look something like:
Code:
And where there's a 1 in the matrix, the checkbox is pre-checked. After the user (un)checks boxes in DCS, a new matrix [A] is returned with updated values.

I just don't know where you'd get labels for the boxes? perhaps a modified Menu(?

Semi-related, how far can you modify these functions? Maybe you don't want to return and execute Menu as normal but instead return a value have the user determine which label to goto. So the Syntax for Menu( & Checkboxes could look like
Code:

Where 'c' would stand for check, 'r' for radio, 'L' for list, etc.

I also recall the Menu( supporting Tabs?

Great ideas Alex. I definitely agree with the list idea for text boxes, etc...

However, what about return values for strings and the like?

We're definitely onto something here, though

Agreed. I wonder if caching is possible... for example, when one scrolls through a list of programs >100 prgms, I've found that it's best to retrieve program names as the user scrolls rather than trying to get them all beforehand (at least in basic)

My concern with something like that is that it's too restrictive. I'd like people to be able to, for example, make titlescreens with images and buttons arranged haphazardly, and have the user click on the button(s) of their choice, for instance, and I'm afraid something like what you guys are describing might prohibit that. Any thoughts? It's also possible that I'm overthinking what BASIC programmers might actually want to do, since it's a long time since I used BASIC.

All DCS would return is what was selected. It'd be pointless to send return values (Strings) to DCS only to have it return one or more back. So, having the program check a return matrix/list for on & off values and going from there.

What is your opinion on the Matrix rather than a list? I for one, would rather prefer a list as BASIC can't use custom matrices.

Regrading it being to restrictive. I've seen far too many non-graphical programs to believe a lot of starting users don't know how to work with the graph screen. And if you provide them with simple tutorials on how to use the graph screen via DCS (such as "Menu(") we might start to see more visually appealing programs.



As for letting a user construct a graph menu of their design, perhaps then a real(#,# would be used instead. This would allow both restrictive and unrestrictive title-screens.

These aren't bad ideas, and I'm starting to formulate more ideas on this count. Putting the GUI-based stuff aside for a second, what about the AP system? Is there any point trying to expose the Associated Program system to BASIC programs, or am I just asking for trouble? Perhaps I should let people stick to CelticIII for editing programs and appvars from BASIC programs?

Hmm, I like the idea actually, how exactly are you thinking about implementing it?

I was thinking I would use one of the existing tokens, for example Celtic's det() token, or a new DCS-specific token. Doors CS lets ASM programs FileOpen, FileSave, and FileSaveAs files, so I would have to expose all three of these to BASIC programs. The only problem is that I'm not sure exactly how to deal with passing data around. For FileSave and FileSaveAs, I know that the filename needs to be a string, but what about the {data pointer, data size}? Do I pass a string for that too, or what? It would be better to still return or pass pointers and size words, but I don't really know how willing programmers are to use provisions in Celtic III, for example, to directly modify memory.

gCn.

EDIT: Assuming, of course, that you're stuck on this calculator thing and refuse to continue work on Multiplicity.