This archive should contain the following files (if it doesn't then it's probably been tweaked by some lunatic who is determined to infect this program with a virus -it can only be a PC owner!).
AutoAppMenu - The main program (small as ever)
AutoAppMenu.info - The icon for the program (smaller than before!)
AutoAppMenu_Background - WBStartUp script file
AutoAppMenu_Background.info - come on, must I tell you everything ?
AutoAppMenu.Doc - well if you haven't found this yet...
AutoAppMenu.Doc.info - ...and you'd be blind to miss it!
AutoAppMenu.Guide - the equivalent AmigaGuide document
AutoAppMenu.Guide.info - with an icon
Documentation for AutoAppMenu V2.0
----------------------------------
It's back! AutoAppMenu has been improved, updated, and generally made a lot nicer to use. I've tried to make sure that it's mega stable, mega fast, and overall quite mega. The only places where the word "mega" is not appropriate is in terms of size of disc space you need for it, and memory. How's that for a plug ?
What's new in Version Two ?
---------------------------
I've added the following improvements since version 1.0 (which was the previous version I put on the Aminet):
* Commodities support (can now be enabled, disabled, and killed by Commodities Exchange). It can also detect duplicate copies of itself running, which the previous version didn't do.
* Now opens a window for command output, if required. This works in the same way as the output window in the Workbench "Execute" menu option.
* Parameters are now passed to menu options. The program will take note of all the icons you have clicked, and will pass them on to the command with their FULL path names. At last!
* For all you icon-lovers out there, I've finally managed to produce a slightly smaller set of icons. Hey, I'm no artist!
* For all techie type people, AutoAppMenu now has a named message port. About time, eh ?
* Arhem! A teeny weeny little bug happened to pop up recently. This showed up if the AutoAppMenu drawer was empty (or filled with non-executable files). Under normal operating conditions, the program ought to shut itself down completely (because it isn't needed). AutoAppMenu DOES actually do this, it's just that it jumps straight back to checking for menu items which aren't there. Sorry to all people concerned for any inconvenience caused. I ought to thank someone from a University in Sweden (Alexander, I think his name was) who kept E-Mailing me with a crashing program, when none of my testing people could reproduce it. Sorry, Alexander! I'm still not entirely certain how this bug slipped through, but I suppose these things happen. AutoAppMenu V2.0 is bug free, honest! I can't tolerate bugs in other programs, so there's no reason why you should have to be subjected to the same torture.
What is AutoAppMenu ?
---------------------
In case you haven't heard of the original AutoAppMenu, it's a program designed to give people an easy way to add options to their Workbench "Tools" menu. If you've used the WBStartUp drawer on your Workbench disc, you're halfway to understanding how to use AutoAppMenu. It works virtually identically (except for the fact that you can't place script files in the AutoAppMenu drawer like you can on WBStartUp). All you have to do is to drag your favourite, most frequently-used applications into the drawer, and next time you boot your Workbench disc, you're Tools menu will contain those options.
Although it's a yucky thought, I got the idea for the program from the Apple Macintosh's "Apple" menu. Naturally, as the Amiga urinates all over the Mac, and the PC (which, to my knowledge doesn't have such a feature on Windows), I thought that I'd prove it by making the Amiga equivalent. The Amiga may not have been designed for lamers (like the Mac), or designed by lamers (the PC), but there's no harm in making things easy, is there ?
Installing AutoAppMenu V2.0
---------------------------
First of all, note that AutoAppMenu requires at LEAST Release 2.0 of Workbench to operate. This is due to the fact that lower Workbench versions don't have the "Tools" menu capability. Well, folks, that's progress!
You don't need vast amounts of memory (or disc space) to use AutoAppMenu. It will hapilly run on even the smallest of memory configurations (I have tested it when memory was EXTREMELY short, and it proved stable). AutoAppMenu is extremely small, so it should be able to squeeze onto the most crowded of Workbench discs (if you have a copy of Turbo Imploder V4.0, you can compress it by about 55% to about 4K).
You can do one of two things to install the program. You can either stick the "AutoAppMenu" icon in your WBStartUp drawer and forget about it, or if you are one of those picky "Have to select Quit" people (yes, I'm one, too!), drag the "AutoAppMenu_BackGround" icon in there, instead. Note that if you do decide to drag the background version into the WBStartUp-Drawer, you must place the AutoAppMenu program in the "C" drawer of your Workbench disc. This is achieved by clicking in your Workbench window (where your WBStartUp drawer is located), and select the "Show/All Files" option from the "Window" menu. Next, locate the directory called "C", and simply drag the AutoAppMenu icon into it. It's as simple as that!
All forms of installation require the presence of a drawer called "AutoAppMenu" to be located in the same place as your WBStartUp drawer. You can create one by selecting the "New drawer" option from the "Window" menu, and editing the name to be AutoAppMenu. If you'd like to start the program straight away, double click on it now, otherwise it will start up the next time you boot your Workbench disc.
Using AutoAppMenu V2.0
----------------------
All you have to do is to drag the icon of any executable (eg. Deluxe Paint, Wordworth etc.) into the AutoAppMenu drawer. The program will update the menu items on the next time you boot the disc (it is possible to do it now, see below for details). That's all there is to it. You can get a menu item to accept input parameters by clicking on an icon (or shift-clicking on many icons), and then selecting the appropriate menu item. This has the effect of notifying the command linked to the menu item of what you've just clicked (the previous version of AutoAppMenu didn't do this, by the way). This can be demonstrated by dragging the "Say" utility (I don't think that Workbench V3.0+ people have this utility any more, so use "More" or something). If you click on some icons, and then select the "Say" option from the menu, you should find that your Amiga starts to speak the names of the icons you have just pressed.
Should you wish to get AutoAppMenu to re-read the directory, you can simply launch another copy of the program. This will trigger a special part of the existing program (the new copy shuts down as soon as it is launched when it discovers that another copy is already running) which generates a requester. This requester asks you whether you'd like to re-read the directoy, or quit AutoAppMenu. In the later case, AutoAppMenu removes all the menu items, and shuts down. If you select the re-read option, the requester will disappear, and the menu items will be updated. Note that if you've got the Commodities Exchange program running, it is also possible to shut the program down from there (ie. click on the "AutoAppMenu" entry, and click "Kill". Ouch!).
If you're a commodities freak, you can change the Tool Type of AutoAppMenu called "CX_PRIORITY". This allows you to change the priority of AutoAppMenu relative to other commodities. You can enter any value from -128 to 127. If you enter a number between 128 (positive) and 255, these will be converted into negative values, where 255 corresponds to -1, 254 to -2, up to 128 being -128. There's no reason why you should want to do this on a regular basis, particularly if you're a beginner. If you do consider yourself to be a beginner, ignore this paragraph.
Error Messages
--------------
In the unlikely event of an error, the program will inform you by generating a requester which details the problem. If there is a problem generating the requester, the screen will flash red.
"Can't access `SYS:AutoAppMenu'": If you have somehow protected the AutoAppMenu drawer from being read, or have a corrupted disc, then the program will not be able to continue, and you'll get this error.
"Can't open Utility Library, reverting to DOS Library": In order to execute the menu items you select from the "Tools" menu, AutoAppMenu has to access something called the "Utility Library". If this can't be opened for some reason (although the chances of this happening ought to be pretty small -I hope!). In this case, AutoAppMenu will attempt to use a different way of getting the same results, by using the "DOS Library". Unfortunately, this is a rather limited approach, which means that menu items would no longer run asynchronously (ie. you can only execute one item at a time). Overall, there is no reason why this library cannot be opened, but this is a warning just in case it does happen.
"Not enough memory to execute command": If you are passing arguments to a menu item (ie. you have clicked on some icons), AutoAppMenu will have to allocate some memory in order to check out what you have clicked. If you don't have enough memory to do this, you won't be able to execute the menu item. As a solution, you may like to try clicking on less icons (if any). This may help the problem. It should be noted that AutoAppMenu will allocate the absolute minimum amount of memory required for this checking process, and although you may be able to avoid this error by clicking less icons, the program that you are running may run short. It should be stressed that this error has a very small chance of occuring. so don't have nightmares!
"Not enough memory to set up AutoAppMenu": AutoAppMenu needs a certain amount of memory in order to set itself up in terms of menu items, commodities, and so on, but if you have not provided enough memory, it will not be able to run. AutoAppMenu will refuse to run in most cases when memory is unavailable for essential features. This error is also quite rare, so if you get it, you must be pushing your machine to it's limits.
"Unable to locate `SYS:AutoAppMenu'": If you have given the AutoAppMenu drawer the wrong name, or have deleted it or something, this error will be generated, and AutoAppMenu will be unable to proceed.
"Unable to open a message port": Message ports are used by virtually all Amiga programs. They are used to allow the Amiga to communicate with programs, to tell them what's happening. In AutoAppMenu, message ports are primarily used for telling the program that a menu item has been selected. If a message port can't be opened, the menu items would not be able to be executed, so AutoAppMenu will shut down. The likely reason for this error is again memory, and as I have said on many occasions, this should not happen to you at all (as message ports are very light on the memory).
"Unable to open Commodities library": The "Commodities Library" is (suprise, suprise) used for creating Commodities. Basically, if AutoAppMenu can't open it, then it won't be able to create a commodity (which it considers essential to it's operation). The likely reason for this happening is (apart from that memory thing, again) that you haven't got a file called "commodities.library" in the LIBS directory of your Workbench disc. This file is placed on the Workbench disc by Commodore, so the only reason for it not being there is due to corruption, or deletion.
"Unable to open DOS library": The "DOS Library" is required for reading the directory. If this cannot be accessed, the program will not be able to proceed. The only likely reason for this not happening is...you guessed it: memory.
"Unable to open files from `SYS:AutoAppMenu'": When you first start AutoAppMenu, it scans each file in the directory to make sure that they are executable. If they aren't, they won't be added to the menu. In order to ascertain whether they are or not, the program has to open each file, and have a peek inside. If the files have been corrupted, or protected, this will not be possible.
"Unable to open Icon library, tool types unavailable": The "Icon Library" is needed by the program for checking the Tool Types. It is possible for the program to proceed without them (the default values will be used, instead), but just to warn you the program produces this requester. It's not likely to occur, though.
"Unable to open output window, output suppressed": If memory is short, and your menu item needs to print something onto the screen, there will not be enough memory to open a window to print it all in. If this is the case, a window will not be opened, and all textual output from the program will not be displayed. I'm sure you don't need to be told about how extremely unlikely this is.
"Unable to open Workbench library": AutoAppMenu needs the "Workbench Library" in order to talk to Workbench, to get those menu items added to the "Tools" menu. If, for some reason this can't happen, AutoAppMenu won't be much use, so it just shuts down. Again, the chances of this happening are so small, it's practically non-existant.
"Unable to read arguments for command": If for some reason, you select an AppIcon, you'll get this error. An AppIcon looks exactly the same as a normal icon. These are generated by programs such as Deluxe Paint, Wordworth, and various commodities. They are designed to have icons dropped in them, but can't be deleted, copied, or executed. If you click on an AppIcon when you select the menu item, you will get this error.
"Unable to read files from `SYS:AutoAppMenu' for identification": If you have protected some of the files in the AutoAppMenu drawer from being read, or they are corrupted, the program will be unable to set up the menus.
"Unable to set up a commodity": In order to allow you to enable, disable, and quit AutoAppMenu using a familiar method (ie. the Commodities Exchange program), AutoAppMenu is a commodity. This means that if for some reason or another, it can't do so, you'd be unable to perform the usual commodity-based jobs. AutoAppMenu will not let you proceed without letting it create one, so if you get this error, then AutoAppMenu will refuse to load.
"You have just launched another copy of AutoAppMenu": This requester gives you the choice of re-reading the AutoAppMenu directory, or quitting completely. Basically, AutoAppMenu V2.0 has a new feature which prevents you from loading AutoAppMenu more than once (after all, there is no real reason why you would want to load it twice -It's not THAT good!). This is not really an error message, but it is a way of quitting the program easily, or updating the menus quickly.
In the next version...
----------------------
Should I manage to produce another version of AutoAppMenu (provided I don't get run over by a sixteen-wheel juggernaught, or get booted out of the University (Queen Mary and Westfield College, University of London)), I'd like to include some of the following things:
* Monitoring the AutoAppMenu drawer for real-time updating of menu options. I had hoped to have been able to figure something out about this for version 2.0, but there you go. If there are any die-hard Amiga coders out there, I'd appreciate any hints you could give me.
* A pop-up window with a more powerful editing system for menu items. I've never really played with the GadTools Library, so I don't yet know what I'm in for!
* A more WBStartUp-like way of doing things. AutoAppMenu currently executes the menu items as if they were run from the command line, and so any programs relying on Tool Types would not usually look at them. WBStartUp seems to execute them as if they had been clicked from Workbench. Also, WBStartUp lets you put script files in the drawer, when AutoAppMenu doesn't. I'm not too keen on this limitation, but in all honesty, I'm completely stuck as to how to implement it. Help!
...and if you have any suggestions, drop me a line. Also, if you have some ideas for implementing some of the above features (and you program in C (or C++), Assembly language, or Basic, I'd like to hear from you.
And finally...
--------------
I must just take this opportunity to thank Sven Dickert from Germany for his help and suggestions (including various icon designs) with regard to the first version of AutoAppMenu. His commodities code gave me a good hint at where to start implementing the support for Commodities Exchange. It also encouraged me to start leafing through me German-English dictionary! I hope that this version meets your approval, Sven (especially the smaller icons!). I'd also like to thank Amiga Format (incontrovertibly the BEST Amiga magazine, along with Amiga Shopper -both of which I subscribe to!) for sticking AutoAppMenu V1.0 on their subscriber's disc. Thanks, Nick!
This is number three on my Aminet contributions list. It's written in 100% assembly language again. Although I've recently got my hands on V6.55 of the SAS/C++ compiler (shame on you, SAS Institute -the Amiga WILL return), the code it generates is several times larger than the equivalent assembly language routines. In addition to this, compiling C++ code takes several minutes, and then there's all those damn types. I'm sticking to 68000! If anyone doubts my ability to be an Amiga freak, take heed: For as long as there are Amigas, I'll be developing for them. As a Computer Scientist, it is my opinion that PCs represent the "technology" (using the term extremely loosely) of yesteryear, and should be erased as quickly as possible (got any semtex ?). The Amiga has far more potential than any other competing "technology", and I plan to prove it. If any Amiga developers are reading, make sure that you do the same.
If you have any suggestions for improvement, or bug reports (please specify machine, Workbench version, and all other relavent details), you can mail them to me at the E-Mail address below. Note that I have tested this program as much as I possibly can on my machine (A500+, 5.5 Megs of RAM (1.5 Chip), Workbench V2.04, GVP HD8+ hard drive), but unfortunately, testing it on other models is a little tricky. Unfortunately, I have to endure the presence of PC, and Mac lamers, and I appear to be the only (loyal) Amiga owner in the whole damn first year! This makes it darn difficult for testing my software on the latest (and most important) version of Workbench. I'm afraid there's not much I can do about it, until I can afford the dosh for a newer machine (if you've got a spare A4000/40 kicking around...). Note also that I follow Commodore's programming guidelines to the best of my (somewhat limited) ability, and I don't do anything funny with the private parts (!?) of system structures.
