Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!jdevoto From: jdevoto@Apple.COM (Jeanne A. E. DeVoto) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <37066@apple.Apple.COM> Date: 7 Dec 89 01:51:37 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <37000@apple.Apple.COM> <6576@drilex.UUCP> Organization: Apple Computer Inc, Cupertino, CA Lines: 48 In article <6576@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson) writes: >It seems that the CommToolBox designers are expecting developers of >existing scripting languages to do violence to their previous product >appearance by exposing the configuration strings to the script-writer. >It is far more likely that developers of such products will hard-code >knowledge of the configuration strings used in the sample tools, so that >the program can retain its previous interface. Possibly, they may expose >the config strings in an 'Advanced User' interface. If they do not, the >variety of the useful CommToolBox tools will be diminished. I don't see any reason why developers need hard-code specific strings for scripting languages. Suppose the existing syntax for setting a terminal parameter such as font size is "set terminal parameter fontSize to 9". To set this parameter using the CTB, the script interpreter would use TMSetConfig (because you are setting a terminal parameter) with the string "fontSize 9". This can be done, clearly, without the interpreter having any specific knowledge of the terminal parameters or their legal values. The *user* will need to know the parameters and values for that tool, but this information should be included in the tool documentation itself. The above configuration will return an error, by the way, since the basic terminal tools use "size" rather than "fontSize" as a parameter name. Since the character position of the bad token is returned, the script interpreter can check the string it sent against the position returned to see whether the problem is a bad parameter or bad value, and post an appropriate user error, e.g. "FontSize is not a valid parameter for the TTY terminal." Again, no special knowledge is needed by the interpreter in this example. If you want a more HyperCard-ish language with defined properties, you can do a getconfig and build a list of temporary properties from the odd-numbered tokens in the full config string. The user could then type something like "set the font to 12". Again, the only requirement is that the tools follow the guidelines for config string format. Any tool that does so will work with these schemes, and the program doesn't need to know anything about the specific tools being used. >Because of existing scripting languages, standardization of configuration >strings will occur. Wouldn't it be wiser, and more Apple-like as well, >to offer some guidelines as to their contents? Guidelines for recommended parameter and value names will be forthcoming from DTS sometime soon (most likely as a technote). -- ====== jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.UUCP | compilation copyright without my permission. ___________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. | AppleLink: SQA.TEST