Hello, Ryshad
Ok, let's go .. I'll give a few comments on your suggestions and then give you an example.
No, you shouldn't. Because the Bay class shouldn't be aware of what's happening outside of it.
Also sounds a bit weird .. if rephrase - it would be "the element of an collection should be aware of other elements in collection "
That's seems the right abstraction level for that design. The Form contains the collection and can be aware of what stored in it. But, probably not passing a color, but calling the right method or calling method with parameters.

Ok, for the first sight that all may seem kinda confusing, but here's example:
Imho, the one of the best methods of explanation - is use of metaphors...

Let's imagine that class is a closed box. If you're inside that box - you can't see what is happening outside (see your a suggestion).

But if we outside the box - we can see some of it characteristics (the methods or data, that you opened for public viewing aka open interface of the class).

Now let's put a few boxes in a row .. we have now a collection of boxes. Now you think, could we see the other boxes from inside of one of them? NO (see your b suggestion).
Now let's imagine, that our boxes are placed on some surface. We can see whole collection of the boxes also as one single element of that collection (box). And here's your form, containing a collection (see your c suggestion).

Now few words about the way your form interact with elements in collection:
You have a surface, with boxes on it .. Now, could the surface know, what color of box should have if it's in the given state? Or rather SHOULD it know that?
If you decided to use OO, then you decided to use some abstraction .. You have Bays, which can be in a few states etc. etc. So you can go further with that abstraction and depending on the Bay state - call methods e.g. draw() (if we have it) or drawStub() (if we haven't it yet) .. (everything this said after assuming, that the On property is publicity visible).

The drawStub() may be static, for the case if you haven't right instance of Bay class right now (but will have in future), but should display the Bay for the further steps.

Hope this will help you

>>Ive always had a problem thinkin in terms of OO...my early projects were coded ENTIRELY on a single form...makes me cringe looking back lol
Same thing here. I still have to support them too

Antenka's points were all the right way to think about it. I have one more approach to add:

You could also create a bay control for the designer that encapsulates your business entity, or extends it with drawing methods. That would keep the business logic tied in at the bay class while allowing a colored baycontrol object to be placed on your form. You could do it the easy way and encapsulate it with a user control but that is no fun!

[edit]
If your color changes based on the the status of the bay then you could implement System.ComponentModel.INotifyPropertyChanged in the Bay class. In the BayControl class you would subscribe to the class if you encapsulate the field and know to invalidate the control and repaint with the new color. If you extend the control then mark the public property as virtual and you could invalidate the control there.
[/edit]

Sorry for not replying guys, i was taken ill end of last week. Still not 100% but i've dragged myself back to work...the world waits for no man :p

Thanks for your suggestions, your explanation helped a lot ddoubled, i had a feeling the first two werent correct OO I'm gonna implement as suggested by having the form chcek the collection then call the appropriate draw() method.

At a later date i will look at seperating the control aspect from the bay class (which i think is what sknake is suggesting) but for now i have far too many projects on the go...wish i had a couple more of me...or better still, wish i had the budget to hire the both of you haha

oops...i meant to sy Antenka, not ddoubled...told you im not quite 100%