We make software for humans. Custom Mac, Windows, iOS and Android solutions in HyperCard, MetaCard, and RunRev LiveCode
HC Tips and Tricks
The HyperCard manual warns you not to colorize your Home stack, because it makes HyperCard slow. However, if you colorize it, and then move the stuff that AddColor installs to the background script (instead of the stack script), you can have color and HyperCard won't be slow, either.
Jon Bettencourt
Kreative Korporation
One big reason not to colorize the Home stack is to avoid interference
between the AddColor scripts in the Home stack and the AddColor scripts
in other stacks. This work-around would avoid that problem too. -- jg
To keep stack size down, rather than importing pictures into the resource fork, we put the pictures into a 'resource folder' which is associated with the stack. So, if the stack was called "test", the resource folder would be called "testRS". The stack first looks in the RS folder which always accompanies the stack, if the file is not found, it looks for a resource folder of the same name on a CD-ROM. This provides us with a flexible environment where we can update stacks at any time on the server, but have large files (such as QuickTime movies, hundreds of photos etc) available locally on CD. When using the "addcolor colorpictfile" command, AddColor will look by default in any paths set in HyperCard's "documents" global. The paths in this global are set by default in the home stack. We have standard handlers which are invoked on open/close stack to add and remove the path of the current resource folder when the stack launches. When we are authoring the stacks we put all pictures in the resource folder, and when using color tools palette, use the "Pict file..." button instead of "import" for adding picts.
Rodney Tamblyn
ETSS, University of Otago
The first time you use the Coloring Tools menu item in a stack, the
AddColor XCMD is installed and its default scripts are added to
various scripts in your stack. In some cases you may not want these
default scripts to be installed. You can install the AddColor XCMD
without its scripts by opening Color Tools from the message box instead
of from the Color menu. Be sure the Color Tools stack is in use (or the
"Color" button in your Home stack is "on",) then from the message box
type:
ac_remoteInstall false
The XCMD and all its associated resources will be installed, but no
scripts will be added to your stack.
Each time you open Color Tools from the Color menu, AddColor will check
for those missing scripts and try to put them back in before allowing
you to access Color Tools. One way to fool Color Tools into thinking
the scripts are already installed, and thus bypassing the demand to add
the default scripts, is to put these lines somewhere in your stack
script (include the hyphens):
-- on AC_Transitions
-- end AC_Transitions
-- on AC_SetTransitions
-- end AC_SetTransitions
-- on colorMe
-- end colorMe
Or alternately, bypass the script check and open Color Tools from the
message box this way:
ac_start
Jacqueline Landman Gay
HyperActive Software
To color an object with addColor using a "ppat" resource: addColor changeObjectBevel,cd|bg,index,(1000-ppatID)*256 Be sure to redraw the card to see your results. You can then set the real bevel in addition to this. In other words, once you have the ppat you can then add a beveled edge. To get rid of the ppat, feed it some large bogus number such as 400 as a bevel, or delete the color.
Brian Yennie
A menu problem I ran into with Color Tools: When you use its color-editing tools, Color Tools will sometimes mash other HC menus. When that happens, it will eventually cause HC to crash. Color Tools apparently fails to check whether the menu IDs it assigns to its menus and submenus are already in use by some other menu -- usually a menu, submenu or popUp menu created by an xThing or xWindow. Instead of checking for an unused menu ID, it always assigns menu IDs in the range 208-215. If a menu already exists with one of those IDs HC will crash sometime later. I first ran into this problem when writing an xWindow that adds a new menu to the HC menubar. Color Tools would mess up the menu and its submenus whenever I used the color-editing tools. By avoiding those IDs when creating my menu, the problem went away. The crash usually occurs when you try to use a menu mashed by Color Tools. (HC crashes because the menu has been disposed of by Color Tools. Essentially, Color Tools created a new menu, assigned a menu ID already in use, then disposed of the wrong menu when it finished.) Another sign of this problem is when menus or submenus suddenly acquire the wrong menu items -- usually menu items from a Color Tools menu or submenu. (If they acquire some other menu items, suspect the xThing that created that menu.) I know of no way to avoid this problem with Color Tools except for other xThing authors to avoid using the menu IDs Color Tools always uses -- menu IDs in the range 208-215. xThing authors should note that the menu id referred to here is *not* a 'MENU' resource id. Rather, it is the menuH^^.menuID. (Normally menuH^^.menuID is the same number as the resouce id, but it doesn't have to be.) Your xThing can assign a new id to menuH^^ before you add your menu to the menu list. To avoid the ids used by Color Tools, avoid assigning a menu id in the range 208-215.
Karl Petersen
An important thing to remember about AddColor is that, with the exception of the "depth" and "remove" selectors, every call will unlock the screen once. To keep color stuff "hidden" in a script with multiple AddColor calls, stockpile some locks.
Stu MacKenzie
There are a few things you can do to speed up color in your stacks. First, try the picture command, if all you are doing is displaying pictures. It may be easiest to use files, rather than resources, if the files are big. It may be fast enough just to do this. Resources will be somewhat faster than files to display. If you are using addcolor, avoid the use of placed objects for display. In other words, *script* the display of the picture. This takes some thought, but the display is very quick. Dramatically faster than displaying placed picture objects (ie., placing picts on the card thru the color tools palette and menus). Do it like this: on openCard addcolor colorPict, "cd", "My Groovy Pict", "0,0", "t", irisOpen, 30 end openCard Note that the parameters for effect and duration (the last two in the line) are optional. No effect is the fastest display (the default effect is "stamp"). DON'T pass openCard, if you have the default addColor scripts in your stack script, because they will call colorMe and wipe the picture. ColorPict is a temporary display (thats what makes it quick, no addcolor index database for the xcmd to access) and will last only until the next call to addColor colorCard, (or colorMe). If it's still slow, take a look at the lockscreen in the closeCard handler in the stack script, or do this in your card script: on closecard end closecard An easy way to position pictures when designing a card is to put a button on the screen, and script the addcolor call like this: on openCard addColor colorPict, "cd", "My Groovy Pict", the loc of cd btn id 1, "o" end openCard Then drag the button around until you get the thing where you want, calling opencard to display it, or put the command line itself in the message box and hit return. All of these calls can be made to files, instead of resources, like this: addColor colorPictFile, [cd or bg], [pict file name], [rect or loc],
[t or o (tranparent or opaque)],[effect],[duration] Another suggestion would be to throw addcolor out the window and make a QT of your pictures and script advances thru the frames of the movie. But if you follow the addColor instructions above, I think the speed of AddColor vs. Quicktime will be roughly equivalent. Which brings me up to the very *last* point. An 8 bit dithered system display will be the quickest. However, if you have pict images which are at a greater bitdepth than 8, make sure in the openstack handler you call addColor in this way: addColor install, 24 -- (8,16,24,32 are the choices. 8 is the default) It helps to call addcolor immediately after the install, so if you don't want to call addColor colorCard, which will result in a white screen if you don't have placed images, call: addColor colorPict(or rect, or field or button), ya da ya da ya da for a rapid display of color in your stack as it opens. I have found that images which have been QT compressed take longer to display than the full size image, because addColor has to decode the compression before display. The tradeoff is speed vs. size of the file. Depends on what you need.
Catherine Kunicki
c@
Tired of having the black hilite of a button (on mouseDown) obscure the color button art work of your color cd or bg PICTs? Here's a neat color button trick I stumbled upon while colorizing one of my stacks. After creating and placing in your stack a color PICT that includes colorized versions of your stack's buttons, set the button properies to "opaque", AutoHilite, & icon to "None". Next, open the icon editor and select an icon of a button that corresponds to one that was colorized in the PICT. Duplicate the icon, note its ID number and then fill in the icon with black, in effect creating a button mask. Save your changes and close the icon editor. Now open the script editor of the same button, paste the following scripts, and insert the icon ID number of the button mask. Save your changes and close the script editor. on mouseUp set the icon of me to "" [some processing if applicable] end mouseUp on mousedown set the icon of me to [ID of the icon mask] [some processing if applicable] end mousedown on mouseleave set the icon of me to "" [some processing if applicable] end mouseleave Assuming the opaque button (or color PICT) is accurately placed, when the mouse is down the color of the PICT will show through the hilited button. You may need to adjust the position of the button mask in the icon editor by a pixel or two to have an exact match with the position of the colorized button in the color PICT. That's it!
Stanley128@aol.com