The dialog boxes are pretty pretty nice nice, but I don't want to require people to use Slib to run my programs. :-/ I've actually become a big Flib fan, so I'll have to see if Slib is better or not. Any feedback?

On the subject of libs, does anyone know of a way to implement zionlib / zlib / or something like that to give non-ion shells ion program running capabilities?

Hmm... what is Slib, and when did it come out??

Slib is another library that is required for many things-like graphics. The problem that prevented its widespread use was that nobody knew where to get it. Now they do.

Where can one get slib with documentation? I've googled but all I could find are basic programs on ticalc that use it.

Isn't documentation included with some?

It isn't better-it's just different.

slib is a flib like librairy made by Samuel Mony (obza_fazer@yahoo.fr) but the doc today is only available in french. I will traduce it soon in english and I will ask its author to put it in librairies folder. Be patient...

Wow, this programs brings bloated, non-standard user interfaces with serious usability problems to TI-BASIC too. As if it wasn't bad enough to see all those ASM games using such interfaces. Was that really necessary? A non-native user interface means:
* you are wasting memory. The dialog box code in AMS is already there, use it!
* you are wasting your (programmer's) time reinventing the wheel.
* interfaces in BASIC are generally slow. I haven't tested this one though.
* you are causing usability problems by presenting the user with another interface than the one he is used to and expects. Wherever things works differently, the user will have trouble getting used to it. (And if things did work exactly the same as in AMS everywhere, then why would you be coding your own interface in the first place?) Consistence is important for user interfaces.
...

...
* you risk causing additional usability problems if you don't know exactly what you are doing. Some of the worst, but way too common, things I could see in custom UIs:
- [ENTER] not working as confirmation key. I have seen all sorts of wierd confirmation keys: [F1], [2nd], ... A confirmation key is not a "fire" key. If you do want to allow confirming with "fire", you should still allow [ENTER]. And if [ENTER] does work, then often only 1 or 2 of the 3 [ENTER] keys on the TI-92+/V200. This is annoying!
- scrolling lists showing only 3 items out of 5 or more simultaneously. There is lots of space on the screen, so there is no reason whatsoever not to use it! Scrolling a list makes sense when there are too many items to fit on the screen. But scrolling through 5 items with a 3-item window is nonsense! And there are so many games with this kind of UI that I wonder what is so special about the number "3"... And sometimes circular scrolling is used in a way (always leaving the center item selected and showing 1 above and 1 below - incidentally, this may also be the explanation of the number 3) which, combined with the small number of elements shown, makes sure you will have no idea where the lists ends. At the beginning or the end of a list, the cursor should go all the way up or down. Don't show the last item above the cursor if the selected item is the first (and conversely).
...

About confirmation keys-there is none here. It's a mouse click, eliminating those problems. If you like a windowed interface using a mouse, this works fine.

Even if there is a mouse I would still expect to be able to navigate the dialog box without it. If that is possible with this program I was unable to figure out how in a short time of playing with it on vti.

For a dialog box replacement I would have hoped for event call backs. Meaning the coder can write code that examines the useres input into the dialog box as it happens.


-Samuel

I wasn't even ABLE to play with it on VTI, I got an "Error: Data Type" when I tried to run his example. '-_-

Isn't it because you didn't remove the comment symbol?
In the home it doesn't work since everything is in one line.

How the devil do you click the mouse?

Try pressing F1, or F2, or Apps, or Enter, or Spacebar, or Q, or 2ND, or HAND, or ALPHA, or SHIFT, or DIAMOND. One of those should work.

And we are back to the confirmation key mess...

No, no...
In fact you can click with the key you want, just esc will quit the dialog box.

>It's a mouse click, eliminating those problems.

No, making them worse. What sense it makes to use a pointer on a platform without a pointing device is beyond me. Keyboard navigation is much more effective.

I agree. In the built-in dialog box design code, you can simple use a single press of an arrow key to move from one entry to the next. Using a pointer requires you to hold an arrow key down, then press a confirmation key (a 'mouse click'), which is both a waste of time and processing power.

...
- unreadable text, due to either lack of contrast (dark gray on light gray, starfield effects obfuscating the text, ...) or unreadable fonts
Luckily, this particular Dialog Box Maker doesn't look like it is affected by any of those. However, I think its "mouse" pointer qualifies for this list. A calculator has no pointing device, so a pointer is more an annoyance than a help. It is unavoidable for drawing or geometry (and in fact TI uses it in those cases), but it is way out of place in a dialog box. Pointing a pointer to an entry field with cursor keys is a waste of time. It is way quicker to simply move the text cursor to that field (does Dialog Box Maker even allow that?).
* your dialogs will usually miss features, such as the advanced editing features in AMS textboxes.

The mouse pointer is hidden while typing, and it looks pretty fast to me.

The issue is not the "mouse" pointer being shown or hidden, but the fact that moving from one control to another using a pointer is much slower (and by this I don't mean the program is slow, but the user takes more time to do it) than doing it with the keyboard. Especially without a pointing device (which cursor keys clearly are not).

True, so true. You miss a TON of AMS features this way. But, if this were in ASM, it wouldn't be "reinventing the wheel", since it could be used in PedroM, where there is no dialog box routine. Although, the other problems still exist.

The dialog boxes in DBM seem to be a combination of Windows and TIOS dialog boxes, without the better features of each. (Enter doesn't work to press OK, no TAB button for jumping, and arrow keys can't jump to another input box, since they're used up for the mouse)

IMHO, one of the biggest problems with making a cursor w/o a pointing device (mouse) is: it takes up the arrow keys, which are usually needed, taking away the whole point of making a cursor (to free up the arrow keys for other tasks). It would really help if calculators had two sets of arrow keys.

<< But, if this were in ASM, it wouldn't be "reinventing the wheel", since it could be used in PedroM, where there is no dialog box routine. Although, the other problems still exist. >>

Actually, some of the dialog box ROM_CALLs _are_ implemented in PedroM. But not all of them. And the dialogs could look better (they are still missing the OK/Cancel "buttons", for example).

"Pointing a pointer to an entry field with cursor keys is a waste of time. It is way quicker to simply move the text cursor to that field (does Dialog Box Maker even allow that?). "
I will think about your suggestions and maybe add "(" and ")" (or F4 F5) to jump between items.

The point is probably to make it look like Windows.

P.S.:

The dialog box code is in AMS, but not the calls (Dialog: Title: Text: Request: DropDown: EndDlog), which end up being much longer than a Dialog Box Maker (hereafter DBM) call. Plus, you can't do as much with AMS as with DBM.