dla formularzy najprościej tak jak pisał Darek, przekaż jako parametr w konstruktorze, a obiekty, do których chcesz mieć dostęp, zaimplementuj jako właściwości, public lub internal.
Jeśli podczas wykonywania programu z punktu widzenia logiki aplikacji może/mógłby istnieć tylko jeden obiekt danej klasy, wtedy można pomyśleć o użyciu wzorca singleton (prywatna statyczna składowa klasy przechowująca referencję do obiektu tej klasy, prywatny konstruktor i publiczna statyczna metoda inicjalizująca i zwracająca referencję przechowywaną we wspomnianej składowej) - odpada wtedy potrzeba przechowywania/przekazywania referencji do potrzebnego obiektu do wszystkich innych klas, które będą go potrzebować.
johny_bravo napisał(a)
Poza tym jak chcesz go zmienic, to musisz uzyc delegacji i metody Invoke, zeby uniknac konfliktu watkow (dwie formy, dwa watki). To co powyzej i to o czym pisze bylo juz pare razy na forum.
jeśli się mylę to mnie poprawcie - formularze są tworzone i operują w tym samym wątku - wszelkie odwołania z ich poziomu do składowych / metod są ok.
Problemy pojawią się dopiero wtedy, kiedy zostanie utworzony nowy wątek, który spróbuje odwołać się do np. kontrolek utworzonych przez inny wątek, np. ustawić tekst w textboksie. Aplikacje Windows Forms mają domyślnie metodę Main udekorowaną atrybutem [STAThread] (single thread apartment) co powoduje, że wątek wykonujący Main wchodzi w ten tryb i wywołania do np. kontrolek lub obiektów COM trybu STA z poziomu innych wątków musza być przeszeregowane (marshalled - tak to się tłumaczy?) na ten wątek i wywołane z jego poziomu (np. dla kontrolek - przez dziedziczonę metodę Control.Invoke). To z kolei wynika z architektury Windows, na której oparte są Windows.Forms.