PenFore, failed attempt to use API as documented, scoping issue?

[Karen Pittman]

I am trying to create a Vectorscript Palette with a number of scripts that, when run, will set the defaults for pen size and pen color. This script, when run, does what I want:

PenBack(0,0,0); {make pen background black}

PenFore(8); {make pen foreground darkish gray}

PenSize(1); {1 mil pen size}

However, it is taking advantage of an undocumented and possibly deprecated feature, in which PenFore, when provided only one argument, will treat it as a color index.

When I try to write a proper script, it doesn't work. Here's the attempt:

PROCEDURE SetLightest;

VAR

r : INTEGER;

g : INTEGER;

b : INTEGER;

BEGIN

PenBack(0,0,0); {make pen background black}

ColorIndexToRGB(8,r,g,b); {get rgb values for color index 8}

PenFore(r,g,b); {make pen foreground darkish gray}

PenSize(1);

END;

Run(SetLightest);

Running this script by double-clicking on it in a script palette has no effect on the pen color or size. Is this some sort of variable scoping issue?

Thanks,

-Karen

[Pat Stanford]

R,G B need to be LongInt not Integer. Also we (several of the longtime scripters) have found cases where the length of the variable name influences how the script runs. 4 or more characters seems to always be safe, but I usually use 2 characters.

I have also run into problems where a single character (Say L for example) is interpreted as a criteria instead of a variable. I now use R1, G1, B1 for safety.

The pensize is a very small number. Remember that it takes 14 units to make one pixel. Unless you are setting in increments of 14 or more, it will be very hard to see on screen a pensize of 1.

[Karen Pittman]

Thanks, Pat, that's all it took! Now I will pay more attention to argument typing. Should I have expected the compiler to notice that mismatch? It didn't, which is why I was lazy with typing...

Cheers,

-Karen

[Pat Stanford]

Maybe the compiler should have caught it, but maybe not.

It is valid to assign an Integer to a LongInt, or to use an integer in place of a longint.

The problem is that since the return was a longint that was being stuffed into an Integer, it was giving bad results (ie negative numbers from the overflow).

So, yes, you need to keep track of the Integers and LongInts. The compiler would have caught it if it was a string (or boolean) that you tried to use in place of a LongInt. I don't know what would have happened if it had been a real.