Version 24 of Simple Program Menu

Updated 2009-06-19 21:04:00 by MHo

I recycled an old program from DOS days and created a tcl prog which reads a script file at startup and present this as hierarchical menus. I need this to work on several inhomogenous systems where the icons where here and there and everywhere and nowhere, and I need a way to quickly run things.

Every menu item could be a complete tcl script, with some restrictions and some helper routines like "select" or "msgbox".

Example of a dialog screen with an open sub selection menu:

http://home.arcor.de/hoffenbar/prog/menue.jpg

Some words about keys and functions:

  • <Return> starts the selected item, that is: going down in the hierarchy or exec'ing the underlying commands.
  • <Hotkey> locates and starts the first matching item (top down). Hotkeys are not shown so far.
  • <.> goes up one level up in the hierarchy (or <BackSpace>).
  • </> goes to the root menu (or <F10>).
  • <F1> shows minimal help and some infos.
  • <F3> shows the commands behind the current item.
  • <F5> reloads the menu-definition files.
  • <Ctrl><c><Ctrl><s> shows console.
  • <Ctrl><c><Ctrl><h> hides console.
  • <Ctrl><f> perform a search in result (text) windows.

__________________________________________________________________________________________

The programm loads all files *.mnu (in that order) out of

  1. the (VFS-)internal dir plugin;
  2. in the program (.exe) directory;
  3. all folders specified via the --mnuDir "folder [folder [...]]]" switch -or- in the current directory (pwd).

Those .MNUs can initially (at the root level of parsing) contain only a very limited set of commands (which are the heart of the whole machinery...):

  • menu {title {code {}} {condition {}}} - adds a submenu. Menus nest. Each menu entry ends with three dots ...
  • app {title {code {}} {condition {}}} - adds an entry in the current menu (the initial menu, root, is automatically created, so it's possible to add app statements outside any menus)
  • @startmenu - a kind of macro: dynamically including the current users and all users startmenu entries at the current position through adding app-entries as if they where directly specified

where

  • title is the text that is shown in the listboxes as a title for applications or submenus (in the latter case suffixed with ...)
  • code is the (tcl-)code to be executed, if an app was selected and started via return or double klick. In the case of menu, code can only contain other menu or app statements.
  • condition, if specified, controls if the menu or app is visible (if the tcl code in condition evaluates to true) or not (if the tcl code in condition evaluates to false). This is one instrument to build menus dynamically depending on the current machines environment)

If an app-title begins with an asterisk * it is "executed" right after the start of menue.exe, as a simple kind of autostart mechanism (without any control yet, though).

(...Description to be continued... - a simple example for the structure of a .MNU-file should be added here!)


Additionally, the file(s) *.mak are sourced only once at program load time in that order:

  1. the (VFS-)internal dir plugin;
  2. in the program (.exe) directory.

They could contain almost any tcl command and some tk commands, and are not intended to be edited by an end user. For this reason the pwd and other dirs are not parsed for makros. Some internal macros are part of the exe, containing some usefull (at least for me) procs, like

  • start {what {confirmWarning 1}}
  • askExec {what {title "Wirklich ausführen?"}}
  • cmd2file {cmd {ext ""}}
  • address {addr cmd {async "1"}}
  • tempName {}
  • readFile {file}

...and some more which are probably too specific and not of common interest (they will be removed in future releases). The following commands are "built in"; they are always available (unless overwritten by user macros, of course):

  • select {items {title "Auswahl:"} {opt ""}} - Display a subselection list like in the screendump above; opt not used yet...
  • cmdLineHelp {title txt args} - shows a scrollable textbox with output results of commands, for example
  • YesNo {msg} - for now, the title is fixed and cannot be specified
  • AlarmYesNo {msg} - same as above
  • msgBox {msg {title "Info:"}} -
  • msgBoxE {msg args} - title fixed - don't know in what state I was programming that...
  • subTitle {text} - sets the centered text at the top of the screen right below the title line
  • scrW - is just a shorthand for winfo screenwidth .
  • scrH - is just a shorthand for winfo screenheight .
  • askValue {prompt {title "Eingabe:"} {width 40}} - like VB's inputbox; if width < 0, the input is hidden
  • console - just the console command
  • statusLine - sets (overwrites!) the status line at the bottom of the screen (should be better divided into a program and user area)
  • tk_chooseDirectory - just that (don't know why I don't created an alias for this...)
  • tk_getOpenFile - just that (don't know why I don't created an alias for this...)
  • tk_getSaveFile - just that (don't know why I don't created an alias for this...)
  • tk_messageBox - just that (don't know why I don't created an alias for this...)
  • tk_dialog - just that (don't know why I don't created an alias for this...)
  • setDefaultValue - sets the default value for a askValue-dialog (because of compat I was too lazy to add another arg to askValue...)
  • getDefaultValue - gets the default value of a askValue-dialog

cmdLineHelp is, despite of it's name, of general interest. It can be used to show the results of commands in a scrollable and searchable (Ctrl+F) Box.

You can find a copy of the program here: [L1 ].

Because the menu files I made are very specific showing some internals of our company, I can't include them in the .ZIP or as an example here.

The program now only has one command line switch --mnuDir. Current version as of June 2009 is 0.88. I have 100 ideas to improve it, but too little time. In fact, the program is far away from the capabilities of it's DOS ancestor or being complete...


Known issues:

  • Importing the system's startmenu entries via @startmenu sometimes lasts very long, because some genious program designers populate the startmenu with all kinds of (unstartable) junk... A kind of interpretation should take place (file executable won't help much).

(Sorry for the many edits - old versions of this page could and should be deleted...)