HyperActive Software

Home What's New Who We Are What We Do Solutions Resources

We make software for humans. Custom Mac, Windows, iOS and Android solutions in HyperCard, MetaCard, and RunRev LiveCode

Resources...


HyperCard Tips and Tricks: Color

Coloring the Home stack

Posted: 2/25/01
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


Remote color files

Posted: 11/26/97
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



Prevent Color Tools from installing default scripts

Posted: 11/24/97
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



The ppat trick

Posted: 11/24/97
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



ColorTools menu bug

Posted: 11/24/97
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



AddColor lockscreen behavior

Posted: 11/24/97
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



Fast addcolor scripting

Posted: 11/24/97
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@



Scripting color buttons

Posted: 11/24/97
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


Up to top | HyperCard Tips and Tricks