[C#]Gdzie stworzyć obiekt i obsługa jego wyjątków

Witam !

Jak każdy na tym forum piszę program i napotkałem pewien problem którego nie potrafię sam rozwiązać.
Chcę stworzyć dwa obiekty przy starcie programu które będą używane przez cały okres jego działania. Zależy mi aby obiekty były dostępne z każdego miejsca programu. Program zawiera więcej funkcji ale okroiłem go żeby pokazać o co mi chodzi.
Problemem jest obiekt MT i dde. Na początku obiekty tworzyłem w odrębnej funkcji jednak znikały one po opuszczeniu jej bloku. Przypuszczam że zadziałał tu GarbageCollector. Dlatego też umieściłem ich tworzenie na samym początku programu. Rozwiązanie działa, tylko jak dodać obsługę wyjątków dla tych obiektów ? Przypuszczam że cały program źle projektuję. Może mi ktoś doradzić jak zrobić to po „fachowemu” ?

namespace mojProgram
{
    public partial class Form1 : Form
    {
        public int tickCount = 0;
        PointPairList list = new PointPairList();
        MetaTraderDde dde = new MetaTraderDde("");
        MetaTrader MT = new MetaTrader(null, 0);

        public Form1()
        {
            InitializeComponent();
            CreateChart(zg1);

            string symbol = "EURUSD";
            dde.OnQuote += new EventHandler<QuoteEventArgs>(MT_OnQuote);
            dde.Connect();
            dde.Subscribe(symbol);
        }
       

        private void MT_OnQuote(object sender, QuoteEventArgs args)
        {
            Console.WriteLine(args.Symbol + " " + args.Bid + " " + args.Ask);
            this.Invoke((MethodInvoker)delegate { bidAskLabel.Text = (args.Bid.ToString() + "  /  " + args.Ask.ToString()); });
            list.Add(tickCount, args.Bid);
            tickCount++;
            GraphPane myPane = zg1.GraphPane;
            myPane.CurveList.Clear();            
            LineItem curve = myPane.AddCurve("label", list, Color.DarkRed, SymbolType.None);            
            curve.Line.Width = 1.5F;
            myPane.AxisChange();
            this.Invoke((MethodInvoker)delegate { Refresh(); });
        }
    }
}

Zależy mi aby obiekty były dostępne z każdego miejsca programu.

Sorry Winnetou, no way. (Tzn takie coś to w 99 lamerstwo które zaprzecza idei programowania obiektowego...)
Możesz jedynie zrobić tak dla jednej klasy (dopóki nie dzielisz programu na klasy tylko wszystko robisz w formie to się tym nie przejmuj ;) ).

Dobra, kończę ten wykład :]

Nie możesz zrobić na przykład tak:?

    public partial class Form1 : Form
    {
       // deklaracja
        public int tickCount;
        PointPairList list;
        MetaTraderDde dde;
        MetaTrader MT;

        public Form1()
        {
            InitializeComponent();
            CreateChart(zg1);

            // Inicjalizacja
            // obsługa wyjątków czy co tam chcesz 
            public int tickCount;
            list = new PointPairList();
            dde = new MetaTraderDde("");
            MT = new MetaTrader(null, 0);
         }
    }

Dziękuję bardzo, pomogło :) Wiem że jestem lamerem dlatego też napisałem o swoim problemie na forum. Ciężko jest się przestawić z programowania strukturalnego, tym bardziej jeśli pisało się pod asm dla mikroprocesorów. Rozumiem że rozwiązanie powyżej nie jest tak do końca poprawne ? Z tego co piszesz wnioskuje że będę miał problemy w przyszłości.

Wiem że jestem lamerem dlatego też napisałem o swoim problemie na forum.

Z tego co piszesz wnioskuje że będę miał problemy w przyszłości.

Ależ nie, kod powyżej jest jeszcze ok, bo czasami trzeba używać takich zmiennych widocznych w całej klasie - tzw. pola klasy.
Tylko że napisałeś "Zależy mi aby obiekty były dostępne z każdego miejsca programu." - takiego czegoś się nie powinno używać, bo to bardzo ogranicza program i przeszkadza programowaniu prawdziwie obiektowemu. Na razie twój program z tego co zrozumiałem składa się z jednej klasy - "Form1" to właśnie ona. W przyszłości na pewno będziesz pisał programy korzystające z większej ilości klas i będziesz się musiał zastanowić jak zaprojektować architekturę programu.

Tym niemniej mój kod powyżej jest całkowicie poprawny, o to się nie martw :)

Wiem że jestem lamerem (...)

Sam fakt że się o coś pytasz i zastanawiasz nad optymalnym rozwiązaniem oznacza że lamerem nie jesteś :)

Powodzenia w programowaniu ;)

Mój program ma za zadanie rozszerzyć o kilka funkcjonalności program MetaTrader4. Owe dwa obiekty udostępniają mi API i połączenie z MT4. Na dzień dzisiejszy jestem w trakcie pisania pierwszego udoskonalenia, w planach są dwa. Co oznacza że dojdzie Form2 :) Dlatego napisałem „Zależy mi aby obiekty były dostępne z każdego miejsca programu.” bo obie formatki czy klasy jak kto woli będą korzystać z tych samych obiektów MT i dde. Stąd też napisałem „Z tego co piszesz wnioskuje że będę miał problemy w przyszłości.” Niestety nie przerabiałem tego tematu jeszcze. Wiem że kod powyżej jest ok bo zastosowałem go i działa tak jak należy ;)

MSM napisał(a)

Tylko że napisałeś "Zależy mi aby obiekty były dostępne z każdego miejsca programu." - takiego czegoś się nie powinno używać, bo to bardzo ogranicza program i przeszkadza programowaniu prawdziwie obiektowemu.

Zaznaczam, ze nie używałem MetaTradera, piszę z punktu widzenia ogólnego stylu, gdyż w takim się wypowiadałes:

Niemniej, możliwość istnieje, i nazywa się static, której nie raczyłeś podać. Nie ma ona nic na przekór projektowaniu ani modelowaniu obiektowemu (które zresztą też nie jest jedyne i najlepsze) poniewaz klasy tez moga cechować się atrybutami, niezaleznymi od poszczegolnych obiektow. Dyskutowac o jakości, chciejstwach i wizjach na przyszłość można długo, jednak w przypadku gdy się gada przez np. p/invoke z innym systemem, albo gdy sie ma doczynienia z rzeczami ktore z definicji sa pojedyncze, nie ma wiele sensu upartym nieużywaniu static'ow. Jeśli nadal Cię korci, pomyśl o standardowym C# Application'owym Resources, Settings czy ConnectionStrings. Jak dla mnie, jeżeli milik pisze plugin'a, to wszelkie dane łącznikowe do programu-matki są static z definicji, inicjalizowane podczas ładowania plugin'a. Na upartego, można je wcisnać w obiekt 'kontekstu'. I ów będzie static. Na upartego, można obiekt kontekstu sztucznie przepychać przez konstruktory i metody klas plugin'a, ale po co? To plugin. Program-matka jest jeden i w dodatku to on żądzi załadowaniem/wyładowaniem assembly plugina. Static, kropka.

Niemniej, możliwość istnieje, i nazywa się static, której nie raczyłeś podać.

Była na temat static dyskusja na forum ;)
Ale static jest w pewnym sensie niebezpieczne bo wprowadza niejawne połączenie między różnymi obiektami tej samej klasy.

Zresztą jest nawet specjalny wzorzec do podobnych zastosowań - singleton - wykorzystujący właśnie static. Przez niektórych nazywany 'antywzorcem'.

(Żeby nie było - jeśli static jest zasadne to oczywiście należy go użyć. Po prostu nie widzę kodu milika, więc nie wiem jakie jest opymalne rozwiązanie.)