Kiedy migracja robota z MQL4 do MQL5 wymaga przebudowy, a nie prostych poprawek

Inwestor posiadający sprawnie działający automat transakcyjny dla platformy MetaTrader 4 często staje przed dylematem przeniesienia go na nowszą wersję środowiska. MetaTrader 5 oferuje znacznie szybsze wykonywanie kodu oraz zaawansowane możliwości testowania strategii, co skłania wielu traderów do wykonania aktualizacji. Migracja oprogramowania rzadko sprowadza się jednak do szybkiej podmiany kilku linijek kodu. Przeniesienie logiki inwestycyjnej wymaga dogłębnej analizy struktury skryptu, wykorzystywanych wskaźników oraz sposobu zarządzania pozycją. To, czy proces ten wymusi jedynie kosmetyczne korekty, czy stworzenie całego rozwiązania od zera, zależy od poziomu skomplikowania samego algorytmu.

Zmiany w strukturze kodu, obsłudze zdarzeń i wskaźnikach

Zarówno MQL4, jak i MQL5 obsługują programowanie obiektowe, oferując pełny dostęp do klas, dziedziczenia oraz polimorfizmu. Zasadnicza różnica między tymi środowiskami nie polega więc na przeciwstawieniu modelu proceduralnego obiektowemu. Kluczowa zmiana dotyczy podejścia do obsługi zdarzeń, tradingu oraz pobierania danych rynkowych. W nowszej wersji platformy standardowe funkcje wejściowe zastąpiono nowymi. Znane z poprzedniej generacji init(), start() i deinit() ustępują miejsca rozbudowanemu systemowi zdarzeń reprezentowanemu przez OnInit(), OnTick() czy OnDeinit(). Dostosowanie tych podstawowych punktów wejścia to zazwyczaj najprostszy etap prac programistycznych.

Znacznie większego nakładu pracy wymaga zmiana sposobu odczytywania aktualnych cen oraz danych z historii. Konstrukcje oparte na predefiniowanych zmiennych Bid czy Ask muszą zostać zastąpione przez wywołania funkcji SymbolInfoTick(). Zapewnia to większą precyzję i lepszą kontrolę nad strumieniem notowań. Prawdziwym wyzwaniem weryfikującym opłacalność prostych poprawek jest jednak analiza wykorzystywanych wskaźników technicznych. W starszym środowisku funkcja iCustom() lub standardowe wskaźniki zwracały konkretne wartości bezpośrednio w momencie ich wywołania. Nowa generacja języka wprowadza koncepcję uchwytów wskaźników, które inicjuje się jednorazowo w sekcji startowej kodu. Dopiero w głównej pętli programu pobiera się z nich odpowiednie wartości za pomocą odrębnej funkcji kopiującej. Zapis ten wymaga podania pełnej sygnatury CopyBuffer(uchwyt_wskaźnika, numer_bufora, pozycja_startowa, liczba_elementów, tablica_docelowa).

Taka asynchroniczna konstrukcja świetnie optymalizuje zużycie pamięci operacyjnej. Wymusza ona jednak całkowitą przebudowę modułów odpowiedzialnych za generowanie sygnałów transakcyjnych. Specjaliści zajmujący się konwersją strategii, do których należy Oprogramowanie EXPERT ADVISORS Radosław Szafron, zazwyczaj wskazują właśnie blok wskaźników jako główny element wymagający napisania od nowa.

Nowy model zarządzania pozycjami i weryfikacji historycznej

Największa rewolucja architektoniczna dotyczy sposobu realizacji i księgowania samych transakcji rynkowych na koncie inwestora. Starsza wersja platformy traktuje każde wejście w rynek jako oddzielne zlecenie. Wymusza to ciągłe iterowanie po liście otwartych transakcji za pomocą funkcji OrdersTotal(). MetaTrader 5 w swoim bazowym mechanizmie rozróżnia zlecenia oczekujące, transakcje realizowane na rynku oraz ostateczną wypadkową pozycję. W zależności od ustawień rachunku inwestor pracuje w trybie nettingu, gdzie istnieje tylko jedna łączna pozycja dla instrumentu, lub w trybie hedgingu, który umożliwia równoległe prowadzenie wielu niezależnych transakcji.

Funkcja wbudowana OrderSend() wcale nie znika z języka MQL5. Bezpośrednie korzystanie z niej wymaga jednak każdorazowego wypełnienia skomplikowanych struktur żądań, co bywa uciążliwe. W praktyce większość programistów używa wbudowanej klasy CTrade, która jest wygodną nakładką na standardowe API platformy. Udostępnia ona gotowe, bezpieczne metody otwierania, modyfikowania oraz zamykania pozycji. Przejście na obiekty typu CTrade to wysoce zalecana opcja, która mocno upraszcza późniejszy rozwój kodu. Zmienia się także sposób sprawdzania statusu operacji. Wymaga to korzystania z funkcji takich jak PositionSelect() dla aktywnych zagrań oraz HistorySelect() do weryfikacji zamkniętych transakcji.

Zmiany obejmują również obszar weryfikacji historycznej algorytmów na wykresach przeszłych. Tester strategii w nowym środowisku potrafi bezproblemowo obsługiwać wiele instrumentów walutowych w tym samym czasie. Wykorzystuje on ponadto tryb weryfikacji oparty na rzeczywistych tickach rynkowych. Pobieranie danych ze świec historycznych, które wcześniej opierało się na prostym odwołaniu do predefiniowanych tablic cenowych, teraz wymaga stosowania funkcji CopyRates() wypełniającej dedykowane tablice struktur wybranymi informacjami.

Ocena ostatecznego zakresu niezbędnych modyfikacji sprowadza się do rzetelnego przeglądu logiki działania automatu. Proste skrypty pomocnicze oraz podstawowe algorytmy operujące wyłącznie na stałych poziomach cenowych często udaje się przenieść poprzez szybkie zmapowanie starych funkcji wejściowych na nowe eventy. Jeśli jednak strategia intensywnie korzysta z niestandardowych wskaźników, zaawansowanego uśredniania ceny i pętli badających historię konta, próba bezpośredniego łatania starego kodu staje się nieefektywna. Napisanie logiki decyzyjnej od nowa pozwala wtedy w pełni wykorzystać asynchroniczne wysyłanie zleceń oraz szybkość wielowątkowego testera strategii. Zrozumienie nowych mechanizmów gwarantuje, że odświeżony algorytm będzie działał stabilnie w nowoczesnym środowisku rynkowym.