From: erh0362@tesla.njit.edu
Newsgroups: comp.sys.mac.comm
Subject: Module in Microphone II 4.0
Date: 8 Apr 92 20:03:05 GMT
Organization: New Jersey Institute of Technology


	Has anyone been able to use modules in Microphone II 4.0 for 
anything useful yet? They seemed like such a wonderful idea but I've 
been trying to make one, and I've come to the conclusion that the 
implementation was poorly thought out and designed. I had a project 
I thought was ideally suited to a module. I'm writing a series of small 
scripts to add functionality that was left out of Microphone II (like a 
keyboard equivalent for Copy then Paste) and a lot of other small but 
immensely useful things. Since I thought people would want to use these 
scripts with their own scripts that dialed their favorite BBS's and so 
on, rather than just using my scripts alone, I thought I'd distribute 
mine as a module that people could simply load into their own settings 
documents. It was not to be so easy.
	First off I discovered there's no true load module command. 
There is an open module command that's only accessible when you're in 
the script editor. It should be accessible at all times. And even when 
you've opened a module you still don't have "execute privileges" for 
the scripts in the module. To use them you have to open the Script 
Manager, select Module, select the script you want to run, and then 
press run. The scripts that should be in the menu should automatically 
be installed in the menu when the module is opened, and similarly 
scripts that have buttons or icons should automatically install their 
buttons or icons when the module is opened. To allow easy access to my 
scripts I'd have to distribute an extra script to be installed in the 
settings document that loaded the scripts in my module, or rely on the 
user knowing how to run a script that doesn't have a button and isn't 
in a menu.
	Secondly, near as I can tell, the Module Load command in the 
scripting language only works with full path names. I know this isn't 
supposed to be the case, and if anybody can suggest what I might be 
doing wrong I'd appreciate the hint, but I've pretty much convinced 
myself passing a full pathanme to Module Load is the only reliable way 
to load a module. The module fails to be found without a full pathname 
when the module is in the same folder as Microphone or the same folder 
with the settings document (these two are the same in my case) or in a 
folder in the Microphone folder called either "Module" or "Modules." In 
the latter cases Module Load won't find it whether or not I pass the 
module name only or FolderName:Modulename. This makes it very difficult 
to distribute a module for use on other people's systems.
	Thirdly, when I do finally get a module loaded (either by 
asking the user to find it or using ApplicationPath and SettingsPath to 
guess where the module might be) it occasionally disappears; i.e. 
suddenly, for no apparent reason, attempts to use the scripts in the 
module fail with "Cannot Find Script" Errors. That's really annoying. 
And even when the script is loaded and running, option-clicking or 
Command-clicking on its button to bring up the Script Editor and Icon 
Selector respectively, fail!
	The short version of the story is that without a way to 
reliably and transparently load modules, they're not much use which is 
a shame since modules are the only significant increase in scripting 
functionality that actually shipped with Microphone II 4.0. I certainly 
can't rely on anything that's contained in a module in another script. 
Even for simply moving scripts from one system to another they're of 
limited use since if I can only copy one script out of a module at a 
time. I suppose you could export everything out of a module and then 
import itnto the settings document, but that's something of a kludge 
and you can do that from a regular settings document too.
	If there's something really obvious about all this that I'm 
missing, please tell me. I'd love to be able to use modules the way 
they ought to be used, but for now I think I'll just stick to 
distributing and using self-contained settings documents.


Elliotte Rusty Harold		Department of Applied Mathematics
elharo@m.njit.edu		New Jersey Institute of Technology
erh0362@tesla.njit.edu		Newark, NJ 07103