Missing mouse blues. (Amiga Resource) (column)
by Jim Butterfield

There are times when you want to do mouse things but it's inconvenient to use the mouse. Perhaps you have a cramped work area, and the mouse doesn't have grazing space. Perhaps your mouse is buried in a mound of documents. Or your mouse is broken. Recently, I even talked to a poor soul whose mouse had been stolen. Mousenappers? The mind boggles.

You can use the keyboard to do mouse things. The qualifier keys on each side of the space bar and the cursor keys are all you need to do the trick. To move the mouse, hold down one of the Amiga keys (the keys marked A next to the space bar), and press a cursor key. The mouse accelerates as the key is held down, so you'll need to develop a tap-and-release method in order to position the pointer exactly as desired. To simulate a left-mouse button click, press both the left-Alt and left-Amiga keys; for a right-button menu click, hold down right-Alt and right-Amiga keys.

In principle, you can do almost anything with the keyboard that you normally do with a mouse. It takes some skill to handle resizing a window or selecting a menu item, and using a drawing program becomes impractical. Your fingers don't seem to be long enough to reach all the necessary keys; it's best to have a real mouse on hand. Find it, fix it, make room for it, or buy a new one if you need to.

Starting from the CLI or Workbench. Some programs, such as the commands in your C directory, can't be started from the Workbench. You must type the command at a CLI or Shell prompt. Workbench 2.0 has a whole new set of features that allow virtually any program to be launched from the Workbench. If you don't have 2.0, it's no hardship to type the commands, unless your Amiga is as bad at spelling as mine seems to be. (When things go wrong, I always blame my computer.)

Many Amiga programs may be started either way: from the Workbench by double-clicking the icon, or from the CLI by typing the program name. Sometimes, however, the program seems to run differently according to which way you started it. Tasks launched from the Workbench don't always look the same as they do when they are run from the CLI. There are two major reasons for this.

Icon files. First, there may be extra information stored within the icon of the program. The icon is stored in a file that's named the same as your application, except that it tends with the file extension. info.

If you click once on a Workbench icon and then select Info from the Workbench menu, you'll see this extra information in the area called Tool Types. Sometimes this area is empty, and sometimes it contains a lot of data. Use the scroll gadgets to examine the entire list of Tool Types.

When you start a program by double-clicking on its icon, the Workbench reads the .info file and its contents. The Workbench then starts the appropriate program and delivers the extra data from the .info file to the program. This way, you can customize features such as window size, fonts, and colors using information stored in the .info file.

But CLI knows nothing of any .info file and starts a program without reference to any such supplementary data. For example, if you type ZONK, the program called Zonk will begin to run immediately. The Amiga will take no notice of a file called Zonk.info or its contents.

Many programs also allow you to specify options as part of a CLI command line. These options usually serve the same purpose as the data within a .info file. Options, or switches, are often preceded by a dash character. For example, the WordPerfect icon might contain a Tool Types option named WORK AREA. To invoke this same option from the CLI, you would type WP -w followed by the size of work area you needed. As always, check the program's documentation to see how it handles this kind of thing.

Current directory. A second reason that CLI and Workbench programs seem to run differently is related to the program's current directory. When you double-click on a Workbench icon, the current directory is set to that program's drawer. If the program then starts looking for files, it will most likely look in this drawer. Such startup data files may contain pictures, hot-key information, text, or almost anything else.

In contrast, a program started from the CLI will often not change the current directory that is active at that time. If such a program looks for files, it may look in your currently specified CLI directory rather than in the directory containing the program and support files.

Suppose your current directory is RAM: and you decide to start a program by typing its full path name, DF0:SOURCE. The program will start to run and might start to look for special files. Chances are it won't look in DF0:, where the files are actually stored. Instead, it will look in the current directory, which is RAM:, and won't find the files it needs.

If you suspect that this is your problem with a program started from the CLI, the fix is easy. Just change the current directory to the one containing the program and support files before you start. In the previous example, you would type CD DF0: and then type SOURCE.