"#210x40x32" will only create pure black maps, but you could create a few and put a
bmap_fill() on some of them with different colors at the start of main to change their color.
[EDIT] Not so simple with BMAPs used by global panel definitions.

... how to make my code react to just the buttons, not the panel itself...
Hmmmm. Let me think on that, it may be do-able.

30 separate panels? I aint going to think about that at ALL!

Proc_kill(4) kills all OTHER copies of itself current running, so only itself remains.
And "this" itself then resets the sizes of ALL the texts, thats really is enough.

Switch is a beautiful little command.
Think of it like this. It is a string of IF's, as it goes through the string,
EVERY time the CASE is a match, this little block of code executes. Then it checks the next one.
Its JUST like a group of IF's you say? But WHOA, just execute one BREAK; from anywhere in there,
and it skips the REST of the CASE's and jumps out of the whole SWITCH block. COOL!
AND, if you put the "case default:" in there, it will run this block every time,
even if NONE if the other CASE's were true.
It WILL run as long as none of the other cases executed a 'break;' command anyway.

this_text is a pointer I made up, and my switch block just "aims" the pointer at the real TEXT object
that "belongs" to that button number, which is stored into butt_over.
Now comes the tricky part.
BOTH butt_over and this_pan you will see in the "pulsate_text" parameter list,
thats where they are coming from.
"But we didnt say to send them in the button!" I hear you say. True, we didnt.
But if you look carfully through the "Button" entry in the manual, you'll find this
Several buttons may share the same function. The number of the button is
passed as the first parameter to the function (1 = first button), the panel
pointer is passed as the second parameter.
Thats how they got sent, so look at my parameter list, and you can see how to use them.

"this_text" is SET in my switch command. thats the only time it gets set in any way.
"this_text" is just a pointer, not a "real" object, and lite-c knows this.
So when we say this_text.font = large50_font;, then lite-c says
"I cant change this_text's font, cause its not an object. BUT it is POINTING
at a real TEXT object, so I'll change the font of THAT object instead!"
This is an easy way to think of pointers. They USUALLY get used this way.

Make "more" sense yet?
Feel free to ask more if you want.

PS Welcome aboard, if I havent already said so...