Is It Perfect?

It's Not Perfect
Sadly, OneClick isn't perfect. Like most programs, there are a number of bugs, conflicts, and annoyances. The chief problem with OneClick at this time (February 1999) is that OneClick has some serious problems with Mac OS 8.5. It is recommended that you don't use both together, though some people have been able to get it to work (with some workarounds and limitations). WestCode Software has promised a new version of OneClick that offers new features and complete 8.5 compatibility. It is expected to ship in March 1999. See http://www.westcodesoft.com/os85.html for more info.

Back Up Your OneClick Folder!
If there is a design flaw with OneClick, it is the fact that palettes can become corrupted. This isn't exactly WestCode's fault -- the Mac operating system is a big part of the problem. What happens is that for a palette to be active, it must be open (in use). If your Mac crashes while one of these palettes is open, it can cause corruption.

WestCode is fully aware of this situation. In fact, they included code to check to make sure palettes aren't corrupted. In the OneClick Folder in your System Folder, OneClick will automatically create a backup of every palette. If OneClick detects corruption, it will replace the damaged palette with an undamaged one. Thus you might occasionally see a message saying something like "The palette Claris Emailer Stuff was damaged and replaced with Claris Emailer Stuff."

Unfortunately, sometimes OneClick gets confused, either thinking a palette's corrupted when it's not, or confusing one palette with another. I see the message "The palette Claris Emailer Stuff was damaged and replaced with Userland Frontier Stuff" every now and then. It's annoying, because then my Frontier tools show up in Emailer and there's no tools in Frontier.

When this happens I immediately quit Claris Emailer (where I got the message) and go to my OneClick Folder. I open up the "Button Palettes" folder and find the "Claris Emailer" and "Claris Emailer damaged" palettes which I trash. Then I open up the "backup" folder and option-drag "Claris Emailer" and "Userland Frontier" items into to the "Button Palettes" folder. This restores my older palettes. I do this immediately so I don't forget (and so I have access to my palettes, which I use all the time), and so that OneClick doesn't start backing up my "bad" palettes (the goofed up ones).

Occasionally (like once a week) I make a backup of my entire "Button Palettes" folder to a different hard drive. I could write a OneClick script to do this, but since I have Connectix Speed Doubler 8 installed, I just use its Scheduled Copy feature to do the backup automatically.

Save Your Palette!
OneClick isn't billed as a programming environment, though I use it as one. It's far faster to use OneClick to prototype something, or just whip out a quick text processing utility. OneClick is so powerful it can nearly do anything. In fact, it's possible to crash your computer with OneClick -- now that's power!

To crash OneClick, try this: edit a palette that belongs to a particular application. While editing a button's script, put in a deliberate typo, something that would cause a syntax error. Now, with that script still visible, use the application menu to switch to a different program. OneClick will become very confused: it technically cannot allow you to close the script because there's an error, but the script cannot be edited while in a different program because that script belongs to the other application! WARNING: Try this at your own risk. It could cause you to lose data!

If you crash while editing a palette, bad things can happen. The most likely is that the most recent changes you made are lost. Almost as often, the palette you are editing will become corrupt and completely uneditable. If you've spent a lot of time creating a palette and writing scripts (and drawing icons!) this is a disaster. Usually your backup folder won't have a current copy of the palette.

What I do is frequently backup my current palette while I'm creating it. This has saved me more than once. What I do is periodically, usually after I've just finished making a bunch of changes (but before running any script), I go to the Palette Editor and choose "Export Palette" and save the palette to disk. I append a number of the palette name, saving two to five versions of the palettte (depending on how complicated a palette it is). Eventually I start overwriting the earlier versions. This way I'm always sure I've got a fairly current backup copy of the palette.

Assigning Shortcut Keys Via Scripts
Technically OneClick makes it easy to assign a shortcut key to a button via a script. You use the button.KeyShortCut command. However, OneClick has problems assigning shortcut keys via a script. It can crash your computer, or work just fine. You never know until you try it -- so try it with caution, plenty of backups, and be prepared for a system freeze.

Calling Other Buttons
One of the features of OneClick is the ability to "call" one button from another. Unfortunately, this has been implemented poorly -- variables and loop states in the calling button are not properly stored. This means if you have a loop which calls another button 10 times, the other button will only be called once. After the first call the first button forgets the loop state! There are some complicated workarounds, but it's not pretty. In short, don't think of other buttons as subroutines -- they are not.

Global Variables
Because of the problems transferring variables from one button to another, it's tempting to use global variables as a solution. Be careful of this approach, however. Global variables are global -- that is, once created they exist for all palettes of that application. This can cause problems, especially with global palettes, since those are active in all applications. For instance, if you create a global variable called "myStuff" in one palette and another palette tries to use a global variable named "myStuff" -- both palettes are accessing the same variable. For your own palettes you can control this, but if you are giving your palettes to others or using palettes from others, the chances of global variables overwriting each other increases. The moral? Use globals as rarely as possible, only when there's no other solution.

Limitations to OneClick
OneClick has a powerful scripting language, but it isn't 100% complete. One of the most frustrating aspects for new scripters is struggling to get something to function not realizing that what you are attempting is beyond the capabilities of the software. So here I'm going to list a few of the limitations of OneClick that new users may assume OneClick can do.

Edit Text Field
OneClick can simulate most dialog box elements like radio buttons and checkboxes, but it has no Edit Text field. For a user to edit some text, you must have them click a button and edit the text in a dialog box. This doesn't make for the best interface, but it is doable. The biggest problem is that it's only appropriate for small snippets of text -- there's no way for a user to edit pages of text within OneClick.

Scrolling Text Field
OneClick also does not offer scrollable text fields. This means any text displayed must fit within the palette's dimensions. There is a scrollable list field in a dialog box via the "asklist" command, but again, that's not the most efficient interface.

Subroutines
While it has nearly every feature of a high-level language, OneClick unfortunately has no support for subroutines. This makes complex scripts more of a hassle to program and debug.

Floating Point Math
OneClick does not support floating point (decimal) math. This makes creating something that uses calculations (like a floating calculator) more difficult to program. It's doable. If you are a math whiz there are ways around this, but it's not pretty or convenient.