@DATABASE "CLICon" @$VER: CLICon.guide 3.09 (13th Oct 1997) @(C) THOR Software @SMARTWRAP @AUTHOR Thomas Richter @NODE MAIN "CLICon Guide" CLICon Guide First Aid for CLICon © 1989-97 THOR-Software inc. Guide Version 3.09 CLICon Version 3.06 I @{"The Licence" link LICENCE} Please read this first! II @{"What it does" link CLI_OVERVIEW} An Overview about the aim of this program III @{"Installation" link CLI_INSTALL} IV @{"First steps" link CLI_FIRSTSTEP} V @{"CLICon ToolTypes" link CLI_TOOLTYPES} VI @{"CLICon Arguments" link CLI_ARGS} Rules of bracketing... VII @{"Problems" link CLI_CAVEATS} What can be done wrong... VIII @{"WBLoad" link CLI_WBLOAD} An additional tool or CLICon upside down. IX @{"History and Credits" link CLI_HISTORY} My Address: Thomas Richter Rühmkorffstraße 10 A 12209 Berlin Germany EMail: thor@einstein.math.tu-berlin.de WWW: http://www.math.tu-berlin.de/~thor/thor/index.html Wisit the Web! Find out about latest versions of my programs, and a useful number of links. @ENDNODE @NODE LICENCE "The Licence" The THOR-Software Licence This License applies to the computer programs known as "CLICon" and "WBLoad". The "Program", below, refers to such program. The programs and files in this distribution are freely distributable under the restrictions stated below, but are also Copyright (c) Thomas Richter. Distribution of the Program by a commercial organization without written permission from the author to any third party is prohibited if any payment is made in connection with such distribution, whether directly (as in payment for a copy of the Program) or indirectly (as in payment for some service related to the Program, or payment for some product or service that includes a copy of the Program "without charge"; these are only examples, and not an exhaustive enumeration of prohibited activities). However, the following methods of distribution involving payment shall not in and of themselves be a violation of this restriction: (i) Posting the Program on a public access information storage and retrieval service for which a fee is received for retrieving information (such as an on-line service), provided that the fee is not content-dependent (i.e., the fee would be the same for retrieving the same volume of information consisting of random data). (ii) Distributing the Program on a CD-ROM, provided that the files containing the Program are reproduced entirely and verbatim on such CD-ROM, and provided further that all information on such CD-ROM be redistributable for non-commercial purposes without charge. Everything in this distribution must be kept together, in original and unmodified form. Limitations. THE PROGRAM IS PROVIDED TO YOU "AS IS," WITHOUT WARRANTY. THERE IS NO WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE ALL FILES CONTAINED IN THIS ARCHIVE. @ENDNODE @NODE CLI_OVERVIEW "Overview" Like the IconX program that came with the workbench, CLICon is used to launch shell scripts from the workbench, via icons. Nothing new, you might say... Additional to what IconX does, CLICon icons might get activated together with additional icons, extended-selected with the shift key, which names, devices and volumes are given as @{"arguments" link CLI_ARGS} to the shell script. But note, however, that you have to shift-select the CLICon icon FIRST! Due to the arguments, the scripts are very flexible and can emulate the behaviour of complete workbench programs (see the examples). A typical example would be a floppy installer icon - if activated together with a volume symbol, the selected device gets initialised - and much more. CLICon can be configured with a real big bunch of @{"ToolTypes" link CLI_TOOLTYPES}, you even do not need an editor to setup a CLICon script! @{B}Applications:@{UB} -Creating assigns for programs that really need them when starting them. (I hate those tons of assigns in my User-Startup. Seems like every author thinks his tiny application needs another dozen of them.) -Create icons for programs that usually can only be launched from CLI (XOper, debugger like MonAm etc.) -Start compilers or assemblers by a press on a button, complete with selection of source code and help texts. -everything else you can think of... @ENDNODE @NODE CLI_ME "My Address" Thomas Richter Rühmkorffstraße 10 A 12209 Berlin Germany EMail: thor@einstein.math.tu-berlin.de WWW: http://www.math.tu-berlin.de/~thor/thor/index.html @ENDNODE @NODE CLI_INSTALL "CLICon Installation" Just copy the CLICon program in the "SYS:System" drawer of your boot volume, AND NOWHERE ELSE. If you like, install the tool @{"WBLoad" link CLI_WBLOAD} as well by putting in the C: drawer; you don't need it to run CLICon, but it's a useful extension. If you like CLICon's output in german (hey, why are you reading the english guide? This time I created a german one as well...) copy the CLICon.catalog file with the translations into "LOCALE:Catalogs/deutsch" of your startup disk. If your native language is french, you should probably install the "Français" calatogs, just copy it from the "Français" drawer to "LOCALE:Catalogs/Français" - thanks to Franck Gimond for the translation. By the way: Translations to other languages are welcome, send @{"me" link CLI_ME} mail! Additional hints how to create CLICon icons can be found @{"here" link CLI_FIRSTSTEP}. @ENDNODE @NODE CLI_FIRSTSTEP "CLIcon - first steps" CLICon assigns shell scripts to workbench icons. So as a first step you need, uhm, an icon. Every icon of PROJECT type will do fine, I suggest one of the icons in the Examples drawer. If not already setup correctly, change the default tool (really got a project icon?) to: "SYS:System/CLIcon" The FULL pathname is EXTREMLY IMPORTANT! A relative path won't do it for some (rather difficult to explain) internal reasons. Please note that "SYS:System" is the right place for CLICon to go, nowhere else. Next, you should decide where to put the script that should be launched with the icon. You may: i) either put it into the Tooltypes of your icon itself. Every shell command must be preceeded by a ">" sign. For example, you may add the following tool types: @{I} >ed S:Startup-Sequence @{UI} to edit the startup-sequence by a button click (preferably some other editor than "ed", this is just an example...) If more than one command is required, they must appear in the same order in the tooltypes as they are to be executed. FIRST COMES FIRST. To use this mode, set the @{"ToolType" link CLI_TOOLTYPES} "COMMAND" to "INFO", i.e. add @{I} COMMAND=INFO @{UI} However, this is also the default. ii) or save your script as a usual ASCII text under the icons name (without ".info", of course). This is what IconX does. Set @{"COMMAND" link CLI_TOOLTYPES} to "BATCH" for this mode. i) is easier, since no editor is required, ii) is more professional. Additional, you might want to do BOTH, i.e. start a first script in the icon, grapping the arguments there and launch a second usual shell script, saved under the name of the icon later on. You even may save a usual binary file under the icons name, which cannot be launched from the workbench. In this case, a tiny script in the icon should run this program, probably with catching the @{"arguments" link CLI_ARGS} first. The following tooltypes MUST BE SET @{B}IN EITHER CASE@{UB}: @{B}WINDOW=@{UB} Supplies the path where the output of your script should go. Should be something like CON:... or VNC:... (my window handler, comming soon...) If this one is missing, the default "NIL:" is used and all outputs are lost. @{B}FILETYPE=CLICON@{UB} This one is an @{B}ABSOLUTE MUST@{UB}, i.e. it won't work without it. It is used by CLICon to find it's icon amongst the extended-shift selected icons, i.e. the additional parameters. @{B}New in 3.05:@{UB} If you DON'T set the FileType correctly, CLICon emulates the IconX program, see here more about this @{"emulation" link CLI_EMUL}. It is therefore sufficient to replace the default tool of IconX icons with "SYS:System/CLICon", and everything works like it should. You won't get, however, all the CLICon service in the emulation mode, so you should really set this file type correctly! For more information, read: @{"ToolTypes" link CLI_TOOLTYPES} or @{"Arguments" link CLI_ARGS} and for some caveats: @{"CLICon Caveats" link CLI_CAVEATS} @ENDNODE @NODE CLI_TOOLTYPES "CLICon ToolTypes" CLICon icons can be configured by a large set of tooltypes. You find the tooltypes by selecting the script icon with the mouse and choosing "Information" of the workbench icon menu. Please note when @{"creating" link CLI_FIRSTSTEP} CLICon script icons that some tooltypes MUST be present. Now the complete list of all tooltypes: is a boolean argument may be set either to "TRUE","YES" or to "FALSE","NO"; all tooltypes marked with (*) are either not supported by the @{"emulation mode" link CLI_EMUL} or have a slightly different interpretation. @{B}FILETYPE=CLICON@{UB} You MUST supply this entry, CLICon uses it to find the script icon or you enter the IconX @{"emulation mode" link CLI_EMUL}. @{B}WINDOW=@{UB} This tooltype sets the output window and should be usually a CON: or VNC: window. If you like it without window and don't need the output, specify "NIL:", which is also the default. @{B}DISPLAY=@{UB} (*) If set to TRUE, CLICon will wait for a key press after the script has been run. If you select FALSE, CLICon does not wait for a key but start a tiny delay, selectable with the next tooltype, before the window gets closed. However, starting with version 2.0 of the workbench, you should better use a WAIT type console window! (But CLICon works without!) @{B}DELAY=@{UB} (*) If DISPLAY is set to FALSE, this entry specifies the number of seconds CLICon should wait before closing the window. The default is zero, i.e. do not wait. If DISPLAY is set to TRUE, this entry is ignored. @{B}HELP=@{UB} (*) If some @{"lock descriptor" link CLI_LOCKDES} as part of an argument is invalid because maybe the script expects more icons selected together with the CLICon icon, usually a requester pops up. If you want to supply a help text, add it as an argument to the HELP tooltype and it will be presented whenever the script can't be started. @{B}HELPWINDOW=@{UB} (*) Selects the window the help text should appear in, usually a CON: window (which is also the default). If you don't give a help text, this one is also not needed. @{B}HELPDISPLAY=@{UB} (*) Like DISPLAY, but specifies what happens after printing the help string. If set to TRUE, CLICon will wait for a key press, if set to FALSE, CLICon will close the window after waiting for HELPDELAY seconds. Both tooltypes, like DISPLAY and DELAY are somewhat obsolete with version 2.0 of the OS. If you gave no HELP string, this tooltype is never used. @{B}HELPDELAY=@{UB} (*) If the HELP string has been printed and HELPDISPLAY is set to FALSE, CLICon will wait for HELPDELAY seconds before closing the HELPWINDOW. If you set this to 0 (the default), CLICon will close the output path immediately. However, you should better use a WAIT console window which closes on the users demand and should not touch HELPDISPLAY and HELPDELAY. @{B}COMMAND=@{UB} ( can be "INFO" or "BATCH")(*) Tells CLICon where to look for the script. If set to INFO, CLICon looks in the tooltypes, which is also the default: Commands have to be added to the tooltypes in the same order they should be invoked, and must be preceeded by a ">" sign. As an example, you may add the following entries @{I} >echo "Installing drive df0:" >install df0: @{UI} to install a drive on a button press. (Actually, CLICon can to better and may even select the drive to be installed with the @{"arguments" link CLI_ARGS}, but this is not important for the example.) If you set COMMAND to BATCH, then the commands are read from a usual batch file which must be created under the name of the icon with an arbitrary text editor. For both methods, the CLICon @{"arguments" link CLI_ARGS} gets expanded before the script is launched. If you MUST use the workbench releases 1.2 or 1.3, read the @{"caveats" link CLI_CAVEATS}! @{B}EXECUTE=@{UB} (*) Tells CLICon wether the commands should be executed as a shell command script or if a simple script is sufficient. In a command script, program control statements like "if" can be used, but a script file uses more memory and needs the "EXECUTE" command. For this reason and cause it is usually sufficient, "EXECUTE" is set to FALSE by default. Again, there are some @{"caveats" link CLI_CAVEATS} for workbench 1.2 and 1.3 if you set EXECUTE to FALSE. @{B}CD=@{UB} (*) Selects wether CLICon shall set the current directory of the script to the one selected with the "LOCK" tooltype. This can be archived with a TRUE argument, and is also the default. If you DO NOT select the current directory, it is not determinated and dependent of the CLICon and OS version. CD should be only set to FALSE if REALLY necessary or the "LOCK" is needed for something else. In versions 1.2 and 1.3 of the OS, a CD=TRUE makes CLICon scripts much longer to load (in fact, CLICon is loaded twice) because it tries to fix several DOS bugs. However, still in version 2.1 of the workbench some bugs are present that makes it a bit tricky to lauch a script without loosing memory! If you specified the @{"empty icon" link CLI_LOCKDES} for LOCK, CD will be always set to FALSE. @{B}LOCK=<@{"lockdef" link CLI_LOCKDES}>@{UB} (*) This one selects which of the icons you may have selected together with the CLICon script are used for exanding arguments without a @{"lock descriptor" link CLI_LOCKDES}. Also, LOCK selects the current directory of the script if CD is set to TRUE. @{B}CREATECLI=@{UB} Choose wether a CLI should be created when executing the script, which defaults to TRUE (do it). If you set this to FALSE, the command path and the shell prompt of the script is not set up to your default, which might be useful for some purposes. @{B}STACK=@{UB} Selects the stacksize of the script which defaults to the stack you gave CLICon, usually 4096 bytes. If you MUST work with OS versions 1.2 or 1.3, this tooltype gets only used if you selected to create a CLI, i.e. set CLI to TRUE. Otherwise, you have to select the stack yourself, with a "Stack" command. @{B}FAILAT=@{UB} (*) Sets the Failat level which defaults to 10. If the return code of a program exceeds this value, the CLICon script gets aborted. If you specify this option in OS versions 1.2 or 1.3, the "FailAt" command must be present in the "C:" directory. @{B}New in 3.06@{UB}: This keyword sets now the FAILAT value for the CLICon internal failure requester, too. @{B}USERSHELL=@{UB} If set to "TRUE" or "YES", CLICon will run the script with the currently selected user shell instead with the ROM shell. @ENDNODE @NODE CLI_ARGS "CLICon-Script Arguments" Within CLICon scripts some character sequences, mostly brackets, get expanded into pathes, device names, file names etc. The object the argument is related to is either given by a @{"lock description" link CLI_LOCKDES} or by the LOCK @{"tooltype" link CLI_TOOLTYPES}, if no lock description is given. This object is one of the icons selected together with the CLICon script or the CLICon script itself, more below. A general remark about CLICon arguments: It's always a good idea to enclose them in double quotes to allow spaces in path names. The following character strings get expanded by CLICon: \\ The next character is directly inserted into the shell script, without parsing it. The backslash is needed to code a character which is otherwise interpreted by CLICon. A typical example is the ">", used by CLIcon as argument delimiter and by the shell for redirection. So if you need a redirection in a CLICon shell script, you have to use "\\>" for redirection. For example, to run a program in background, you need to write: @{I} run \\NIL: prog \\>NIL: \\". \@* Gets expanded into the full pathname of the CLICon script itself, without any ".info" (the name of the icon is therefor "\@*.info"). Thus "\@*" is identical to "{OWN}" or "{0}". This argument is useful for storing a second script under the name of the icon. $* Gets expanded into total the number of arguments the CLICon script got activated with, encoded as ASCII number string. If only the CLIcon script itself was selected, "$*" is substituted to "0", and with one additional icon to "1". [@{"lockdef" link CLI_LOCKDES}] Gets expanded to the pure file name of the object specified with "lockdef" without any path name and without ".info". Thus the square brackets give only the file name RELATIVE to the directory the object resides in. If this object is a directory, the square brackets expand to an empty string, the same goes for the @{"empty icon" link CLI_LOCKDES}. (@{"lockdef" link CLI_LOCKDES}) Expands to the path of the directory the object resides in, but not to the name of the object itself. It is guaranteed that "()[]" gives always the complete absolute path name of the object itself, thus the last character of the expansion of "()" is always "/" or ":". If the object is itself a directory, "()" is already the complete path. The @{"empty icon" link CLI_LOCKDES} expands here again to an empty string. {@{"lockdef" link CLI_LOCKDES}} Gets expanded to the full absolute path of the specified object, therefor "{}" is identical to "()[]". Again, a ".info" is never added. If the object is a directory, the last character of "{}" is "/" or ":", and the @{"empty icon" link CLI_LOCKDES} gives again an empty string. <@{"lockdef" link CLI_LOCKDES}> This one expands into the device name the object is located on. It lacks the terminating ":", you have to add it by hand if you need it. For the @{"empty icon" link CLI_LOCKDES} the trianglar brackets results in the boot device (E.g. "dh0" or "df0" ). If the object is, for example, saved on a disk in the internal drive, you'll get "df0". Please note that the colon is missing! «@{"lockdef" link CLI_LOCKDES}» Gets expanded to the volume name, i.e. the name of the disk, but again without the colon you'll have to add by hand. The @{"empty icon" link CLI_LOCKDES} results here in "SYS:". The difference between the single and double triangular brackets is that the single brackets "<>" specify the device driver (a piece of hardware like "df0" or "dh0"), but the double brackets "«»" relates to the volume, i.e. the disk like "Work". @{B}Confused?@{UB} An example might clarify the arguments: Assume you shift-selected the CLIcon icon "SCSI:test.info" together with the icon "Oops:Foo/nonsense.info", with is stored on the internal disk drive. The @{"tooltype" link CLI_TOOLTYPES} LOCK is set to "USED". The following arguments gets expanded into: \\> > \\\\ \\ \\A A The backslash gives always the following character. $* 1 $* is the number of additional selected icons, here one. \@* SCSI:test The name of the script icon, but without ".info" \@*.info SCSI:test.info Since all remaining characters are copied directly, this is the pathname of the icon. [] nonsense The file name of the second icon, without ".info" and without the directory part. () Oops:foo/ The directory "nonsense" is located into, with terminating slash. {} Oops:foo/nonsense The complete absolute path, without ".info". <> df0 The device from with "nonsense" was read, here the first disk drive. Please note again the missing colon! «» Oops The name of the disk, again without colon. {0} SCSI:test The name of the script icon, again... {OWN} SCSI:test again... [1] quatsch The name of the first additionally selected icon. [FOREIGN] quatsch [LAST] quatsch [USED] quatsch again... @ENDNODE @NODE CLI_LOCKDES "CLICon Lock Descriptors" Both, the @{"CLICon arguments" link CLI_ARGS} and the @{"tooltype" link CLI_TOOLTYPES} LOCK use the so called "lock descriptors". They specify one of the icons shift-selected together with the CLICon script, whose name, path, device or volume can be inserted into the CLICon script, depending of the argument the lock descriptor is used within. A lock descriptor consists of digits, special short words, the vertical bar "|", or, additional for arguments, the backslash "\\". Here a list of all possible lock descriptors: OWN The CLICon script icon itself... FOREIGN The first additional shift-selected icon, selected together with the script. LAST The last additional extended-selected icon. USED The first additional or, if no additional has been selected, the CLICon script icon. NONE The empty icon. It is always present and expands to something dependent of the argument it is used in, see @{"here" link CLI_ARGS}. A digit: Specifies one of the selected icons the CLICon script was launched with. Number 0 is the script icon itself, number 1 is the first additional icon - so "1" is idential to "FOREIGN" - number 2 the next icon etc. You may separate possible icons with a vertical bar. If the icon number to the left of the bar is not available since too less icons have been selected, the next choice right to the bar will be tried. To give some examples: 2|1 The second icon if available, or the first if the user choose only one additional. Even longer chains of bars are possible: 2|1|0 The second, if not present the first, and finally the script icon itself, if everything fails. "0" itself can't fail (except if the user removed the disk), cause the script is read from this icon! Thus the following possibilities are identical: OWN and 0 FOREIGN and 1 USED and 1|0 The backslash "\\" is allowed only for @{"arguments" link CLI_ARGS} but not for the tooltype LOCK, as the last item on a list of lock descriptors. The text behind the backslash is the result of expanding the argument, if everything else fails. To say it again: The backslash is valid for arguments ONLY, and MUST be the LAST ITEM. Please note that the text behind the backslash gets again parsed by CLICon, SO IF YOU NEED TO INSERT SPECIAL CHARACTERS, ESCAPE THEM WITH THE BACKSLASH. This means if you want to expand the argument to a "(foo)", you'll have to type "\\\\(foo\\)"! The first backslash starts the "last chance" text, the second and third escape the brackets. Again only for arguments, it is possible to leave the lock descriptor completely empty. In this case the argument relates to the icon (or object) selected with the LOCK @{"tooltype" link CLI_TOOLTYPES}. If none of the icons of the lock descriptor is available and no backslash argument is given, CLICon will try to print a help text the author of the script setup with the HELP @{"tooltype" link CLI_TOOLTYPES}. If this again fails, as a last resort a fail requester is generated. Examples: (for more examples involving argumens read @{"here" link CLI_ARGS}) [OWN] Expands to the name of the CLICon script icon (without ".info") [FOREIGN|OWN] Expands to the first shift-selected icon, or the own one if no icon has been selected together with the script. Thus this choice is idential to "[USED]". [2|NONE] Expands to the second additional icon, or to the empty string if not present. [3|2\\foo] Expands to the name of the third icon, or the second, or if the user selected less than two additional (counting the script, totally three) icons, to the text "foo". [NONE\\foo] Always expanded to the empty string since the empty icon is always present. [OWN\\foo] Always the name of the own icon. Where else did this script came from? [1|2] Again some piece of nonsense. The second icon can't be present without the first. @ENDNODE @NODE CLI_CAVEATS "CLICon Caveats" And now some remarks about the CLICon scripts: Caveats with Workbench 1.2 and 1.3 (arghh! Update the OS!) ____________________________________________________________________________ With Workbench versions 1.2 and 1.3 the interactive commands "ask" and "edit" won't work in CLICon scripts. The reason for this is that the input channel is missing (and can't be setup without getting an interactive shell). If you MUST work with these obsolete versions, redirect the input channel to the console, i.e. insert "ask \\<*" or "edit \\<*" for a workaround. The backslash is needed since otherwise CLICon would interpret the "<" sign as the introduction of an @{"argument" link CLI_ARGS}. Again, for the same reasion, with workbench 1.2 and 1.3 you can't interrupt a CLICon shell script with Ctrl-C or Ctrl-C (except you use my own console handler VNC: instead of CON:). Another "feature" for 1.2 and 1.3 is that CLICon scripts can't be longer than 255 characters if the @{"tooltype" link CLI_TOOLTYPES} is set to FALSE. This is a result of the #*?$!-BCPL Dos. Lucky enough, at least these bugs have been removed starting with workbench 2.0. Expansion of arguments in "if" clauses ___________________________________________________________________________ Please note that all arguments gets expanded before executing the script, even those that are not needed since they are part of a "if" clause. As an example, consider this script: @{I} IF (FOREIGN\\FONTS:) NOT EQ FONTS: ASSIGN FONTS: (FOREIGN) add ENDIF @{UI} It results in a fail requester if no second icon has been selected, since CLICon can't expand the "(FOREIGN)" argument. Better replace this line by: @{I} ASSIGN FONTS: (FOREIGN|NONE) add @{UI} This command line is always expandable, but expands to an invalid command line if no additional icon was selected. However, this does not matter since it is never executed, cause it's protected by the "IF". Redirection of input and output ____________________________________________________________________________ For redirection of input and output, the shell uses the special characters ">" and "<", which are also interpreted by CLICon as argument deliminters. Thus you have to add a backslash "\\" before "<" and ">" for redirection in a CLICon script, like in @{I} RUN \\>NIL: \\" the device and "«»" the volume. -Illegal lock descriptors used to expand into the empty icon for versions 2.xx. Starting with 3.xx you get a fail requester, unless you type "...|NONE". -Starting with release 3.xx, CLICon creates a new CLI by default. As a side effect, the command path and prompt of the workbench is used for the CLICon script and not set to the default. In general, this does only good, but may lead to conflicts if two different versions of a command are available. In this case, set the @{"tooltype" link CLI_TOOLTYPES} to FALSE or explicitly remove some directories from the PATH. @ENDNODE @NODE CLI_WBLOAD "WBLoad Guide" WBLoad © 1989-1997 THOR-Software. Please read the @{"Licence" link LICENCE}! WBLoad is an extension to CLICon and in some sense CLICon backwards. WBLoad loads workbench programs from the shell (or from inside a CLICon script) which can't be started from the shell itself. Here again the command line: @{I} WBLoad [WAIT] [QUIET] [TOOL defaulttool] [ICONS] @{UI} the name of the icons must be specified without ".info". As an extreme application, you might even lauch a CLICon script with "WBLoad"! More options: @{B}WAIT@{UB}: Do not return to the shell until the launched command quits as well. @{B}QUIET@{UB}: Don't print loading messages. @{B}TOOL@{UB} @{I}defaulttool@{UI} : Specifies the default tool for project icons. This argument overrides the "default tool" entry in project icons and loads this tool program instead. Useful if you want to load a tool with the CLICon icon as project icon. @{B}ICONS@{UB}: Specifies the icons. These should be either one tool icon and project icons, or only project icons. In the last case the default tool is read from the first icon, or given by the @{B}TOOL@{UB} argument if present. All additional icons are send as extended-selected (like selected with shift) icons to the tool. The names of the icons follow, but the option itself can be ommitted. This option @{B}must@{UB} be the last of the line, together with the icon names. @ENDNODE @NODE CLI_EMUL "IconX emulation mode" The 3.05 release of CLICon provides another feature: It is now backwards compatible to the old "IconX" program that came with the workbench. To enable this emulation (although I recommend the "real thing" instead of the emulation, but anyways...), just do not set the "FILETYPE" @{"tooltype" link CLI_TOOLTYPES} - so changing the default tool of IconX icons to "SYS:System/CLICon" will run them with "CLICon" without any change. The number of tooltypes CLICon knows in this emulation mode is however drastically reduced, and some of them are interpreted in a slightly different way. Here's the list of changes: @{B}WAIT=@{UB} (new tooltype) Similar to the "DELAY" tooltype of CLICon, this sets the delay in seconds before CLICon closes the window after the script has been executed. The delay defaults here to two seconds, not to no delay at all. @{B}DELAY=@{UB} (changed meaning) This tooltype works almost like "WAIT" except that the delay is given in 1/50th of a second rather than in seconds. The following tooltypes are not supported in the IconX emulation @{B}DISPLAY=@{UB} Is always set to "FALSE", CLICon will never wait for a keypress in the emulation. @{B}HELP=@{UB} @{B}HELPWINDOW=@{UB} @{B}HELPDISPLAY=@{UB} @{B}HELPDELAY=@{UB} Online help is not supported by IconX. @{B}COMMAND=@{UB} Is implicitly set to "BATCH" since IconX reads always its scripts from a file. @{B}EXECUTE=@{UB} Always assumed to be "TRUE", IconX uses "Execute" to run its scripts. @{B}CD=@{UB} Always set to "TRUE". @{B}LOCK=<@{"lockdef" link CLI_LOCKDES}>@{UB} Lock descriptors are not supported by IconX. @{B}FAILAT=@{UB} This tooltype is also not supported by IconX. Use an explicit "FailAt" command in the script! The CREATECLI tooltype will work and may set to FALSE, this isn't useful, however. @ENDNODE @NODE CLI_HISTORY "History of the program" CLICon 2.00 First version that works with OS 2.x CLICon 3.02 First AmiNet release. CLICon 3.02.2 CLICon unchanged, but WBLoad has been updated. Thanks to Nikoa Smolenski for the ideas, and for further example icons. CLICon 3.03 Removed a tiny typo in CLICon (one error message was wrong), added the TOOL argument to WBLoad. CLICon 3.04 Added the FAILAT tooltype and changed one requester text for V37 and above slightly. Thanks to Allan Odgaard! CLICon 3.05 Added USERSHELL tooltype and IconX emulation. Nikola Smolenksi had the idea, thanks as usual! Thanks to Franck Gimond for the french localization. CLICon 3.05.2 CLICon unchanged, but WBLoad creates now a reply port for its startup message that seems to be required by some programs. Thanks to Stuart 'Kyzer' Caie for the note. CLICon 3.05.3 CLICon again unchanged, but the faked ReplyPort WBLoad created gets now the Workbench task as signal task. But please, do not depend on this feature, use a FindTask() call instead! CLICon 3.06 The FAILAT keywords sets now the internal threshold for failing, too. If a command returns a lower return code, CLICon won't fail - unlike older versions that showed a failure requester if anything but zero was the result code. @ENDNODE