#Menu Interface?
11 messages in this thread
After many years of using the command interface, I finally crumbled and
wanted a menu interface to my common office work functions like word
processing and spreadsheets, and for my kids to access games. What with
directories of documents, etc., there was just too much that I didn't want
to remember?
I didn't see one lying around for the 'Bow, so I wrote one in Turbo Pascal.
Actually, I started with Marc E Kenig's TurboMenu-RB and added an indexed
file to store the menu data in.
I named it AUTOMENU, which was pretty unimaginative. It turns out that
there's a shareware goodie for the I*M PC with that name, so I'm shopping
for a new name.
I'm also shopping for a decent interface for MAINTAINING the menus.
Myprogram has a built in menu option for menu database maintenance, but
it's so clumsy that I can't use it effectively mysaelf. I have also been
too embarrassed by this shortcoming that I haven't wanted to upload the
program in its current state.
It allows for a hierarchy of menus about 10 deep. My deepest menu is three
from the top. It implements options other than submenus by invoking
COMMAND.COM and passing the specified command line to it. I bootstrap it
from AUTOEXEC.BAT, or return to it by calling it up, if I've been doing
commands "A la carte" for a while.
Is anybody else interested in a menu interface like this? It's humbler
than a window, but it beats banging your head against the wall 🙂 If
anyone else IS interested, how would you like to help me design a DECENT
interface for menu database maintenance, so I can write it, and upload the
package here?
I almost forgot, anybody got a good name for such a thing?
David,
Not to discourage you, but I have to ask the obvious question.
With all the *dozens* of MS-DOS menu programs that are over in the IBM
forums, many/most of which (I'd guess) are generic enough to work on the
Rainbow… why?
Call me a cynic, or an old something-else if you want… I hope you're
doing this "just for fun!"
But as long as you asked, the menu system my company uses in its products
(not on MS-DOS) doesn't use ANY kind of "menu database". The menu
descriptions are simply text files. Each line in the file contains a
description of one part of the menu: the (internal) menu name, title,
subtitle, name of a graphic "background" file that is displayed along with
the menu text, and one line for each entry on the menu. Each line is
"tagged" with its function, e.g.:
MENU:Mainmenu
TITLE:"WhizBang Products Corp. Main Menu"
BACKGROUND:"filename"
ITEM:WP,"WordPerfect",RUN:"wp"
ITEM:AF,"Auxiliary Functions",GOTO:Afmenu
ITEM:F,"Finished",RUN:"logout"
MENU:Afmenu
TITLE:"WhizBang Products Corp. Auxiliary Menu"
BACKGROUND:"filename"
ITEM:D,"Directory of files",RUN:"dir"
(…etc.)
Multiple menus can exist within a single text file. Each menu-entry
contains several comma-separated fields; each field is tagged with its
function (except for the "description" part) as you can see above. The 1-
or 2-character "item" legend is what the user types to select the menu
item. Menu items can do different things; GOTO branches to a submenu, RUN
executes a program, and there are others (e.g. READ another menu file).
There is a menu 'compiler' which does syntax verification and produces a
'binary' version of the menu but there is really no advantage to doing
that; the text version, interpreted by a menu 'interpreter', is just as
fast, and will syntax-check each line as it is displayed.
-Bill
You had to ask, didn't you… 😉
Well, here goes,
1) Somewhere along the line, I picked up the idea that most menu
packages did direct screen writes for speed, and that that would
prevent them from running in the 'Bow enviroment. From your comments,
I gather I'm mistaken.
2) The menu packages I looked at only allowed one level of sub-menus.
I wanted more. The one you describe (at work & not for MS-DOS)
seems like it fills the bill.
3) I'm thinking that, if things go well for the menu driver, I could
throw in a forms handler, a VideoText like message handler, and I'd
be a long way towards having a kind of useful information handler.
4) I have a few programs that I've written that use menus (or might
have menus added to them). I'd like the menus to be fairly
consistent.
and,
5) Awright, it is just for fun. I wanted an easy project to get started
with the Turbo Database Toolbox.
I gather, from the deafening roars of encouragement, that I'll probably be
the only user of this here thing. Oh well, at least it won't be hard to
schedule a user's meeting!
BTW, Thanks for sharing the syntax for your menu processor. It's certainly
better than what I have now!
Y'know… it occurs to me, after our earlier messages on this subject and
reading your reply…
I do have *some* interest in seeing my menu program ported to MS-DOS.
There are a couple of reasons: It would give me a clue as to how hard most
of the rest of my code would be to port, and it would begin to establish a
foundation for doing that if I ever want to. Right now I don't think there
is any profit to be made there (and I _do_ do this for a living after all),
but things change and I have been known to be wrong occasionally.
If you, or anyone else, use C on MS-DOS and would have some interest in
porting it as an experiment, I might be persuaded to part with the source
code, or at least with a more complete specification of the menu language.
We would have to discuss terms and conditions though, since I don't think
I'd be willing to see the end product put into the "freeware" public
domain, though I would consider "shareware".
-Bill
I'm not entirely sure what you guys are discussing (a menu system of some
sort that you, Bill, have source code for in a language other than C), but
count me as an "anyone else" for now, at least. I think it was the direct
screen writes that got me. If that's the way you want to go, I have a lot
of stuff on that, most public domain, all Rainbow-specific.
Mike/Roy (Hey, if you can be confused, so can I…)
The menu system I have *is* in C, but it's not written for MS-DOS and
never really had that environment in mind. It's currently supported on
VMS, and has had prior incarnations on UNIX and RSX-11M.
David is working on his own menu system, in Turbo Pascal I think. I
believe he was saying that he thought most of the existing standard IBM PC
menu programs probably used direct screen writes and would therefore not
run on the Rainbow.
Then again, I could be confused even further!
-Bill
Yes, the menu system I've been developing is in Turbo Pas xXX make that
Turbo Pascal.
No, I'm not interested in porting anything that's not PD to the Rainbow. If
we're talking commercial here, I think you have to consider the market.
PD is different. "Just for fun" commands a different market.
Not interested in code, but the specifications for the Menu compiler, and
the resulting compiled menus are of interest. Any chance the specs could
become PD without releasing the code?
That way, the "look and feel" can be ported to MS-DOS!
end of Ramble…
David,
You're absolutely right to suggest "consider the market". I must not
have been clear… what I would want to do is a generic MS-DOS version that
would run on any MS-DOS machine (though I would certainly not be averse to
any Rainbow-specific enhancements ;-}).
I'm not sure what specs for the menu compiler *exist* at this point.
That aspect of the product has been pretty much frozen for several years
now since it has been determined that it really offers NO advantage over
just keeping the menus in plain-text form, and interpreting them. That
might not be true in the memory-constrained MS-DOS environment, though.
I'll have to do some checking around but I am not optimistic that I will
find much of anything. (We bought that portion of the product from another
company and I think all we got was code, no specs.)
-Bill
Bill,
Just guessing offhand, I would doubt that there would be any advantages
to compiled menus under MS-DOS. They would simply have to be kept in a
larger .EXE file as opposed to a separate data file, and it's easy enough
to write a program that uses pointers to read and generate menus.
Matter of fact, a number of MS-DOS programs, including Borland's Quattro
Pro, keep menus in text files so users can customize them. I imagine that
this also makes marketing the programs in multiple languages easier.
— Carl
Carl,
Re: multiple languages, correct.
For the record I'm not *really* talking about *compiled* menus. What I'm
talking about is more aptly described as "preprocessed-to-binary" menus, as
opposed to a scheme where the text must be interpreted by the menu
processor from plain-text form. So we're not really talking about any
impact on a .EXE file… the menus would still be stored in an external
data file, it's just a question of whether the data file contains
human-readable data or not. True compilation would mean generating machine
code… this is more like generating binary data, but the
compiler/interpreter model of understanding seems to fit so well that I use
the word "compiled".
Experience has shown me that the amount of time required by the menu
processor to handle compiled menus is *so* trivially different from that
required to handle plain-text menus, that it's not worth the bother of
maintaining the menu "compiler" (and, of course, maintaining the "compiled"
forms of the menus themselves!).
-Bill
I understood the word "compiled" to mean "made binary for execution". No
confusion here.
I'm a little startled to learn that compiling offers no advantage.
Of course, I'm not doing MUCH "compiling" myself. Basically, just using an
index file mechanism to link the tree together. Actually, embedded record
pointers are probably faster and easier in this case than indexed files,
but I want to let the driver grow beyond menus.
If we are not talking Rainbow Specific, but "generic MS-DOS" we start to
overlap all the Menu drivers that exist for the I*M + clone market, and
this time I get to ask the obvious question: Why?
My interest is Rainbow specific, and I realize full well that that's not
mainstream.