Articles on MetaTrader 5 integration using MQL5

This article defines a Protocol Buffers contract for the MetaTrader 5-Python boundary and implements a length-prefixed Protobuf-over-TCP client in MQL5, since MQL5 cannot speak real gRPC natively. A small Python shim relays those frames to a genuine grpc.aio server, unary today, with streaming already live on the backend. You get schema-enforced, strongly-typed messages, explicit errors, retry/backoff, and a Strategy Tester cache for reproducible backtests where sockets don't run.

The rasterizer now accumulates exact span coverage in X and sampled coverage in Y, and blends it via CairoBlendOver on straight ARGB. CairoAaSamples sets the number of vertical samples at runtime, making the cost nearly linear and localized to edges. Readers get smoother boundaries, correct compositing of translucent shapes, and controllable performance.

Part 3 implements a scanline rasterizer in pure MQL5. We convert path segments into top‑down edges, sweep each row, sort crossings, and apply the non‑zero winding rule to decide which pixels are inside. The result is a single Fill(path, color, buffer, w, h) routine that draws rectangles, stars, glyphs, or 2000‑edge shapes without per‑shape code, ready to integrate into your MQL5 projects.

This article shows how a PDF works as plain text by hand‑written two files: a 592‑byte page and an 885‑byte trade ticket. It explains the file structure (header, body, xref, trailer), the required page objects and resources, and the operators that draw text, then provides an MQL5 script to generate them. First part of a pure‑MQL5 PDF library series.

The article discusses the parameters of the second stage of the automatic optimization pipeline for a multi-currency Expert Advisor. We analyze the criteria for filtering first-stage passes and the rules for forming groups of trading strategies. The article demonstrates how settings affect optimization results, discusses aspects of process reliability, and examines the balance between selection strictness and having enough candidates for the algorithm.

Until now, the application being developed as part of this series of articles has focused exclusively on simulating the graphical part. However, to obtain a more complete system in which we can test the Expert Advisor within the replay/simulation service, we also need to simulate the trading server. You'll notice that this simulation will include only the most essential elements. Nevertheless, you, dear reader, will be able to fill in the missing parts. Since these additional components don't affect what I want to show, we already have more than enough to implement what we have in mind.

The article provides a critical analysis of an LLM strategy in which forecasting the direction is separated from trading decisions, and demonstrates why this leads to a disconnect between metrics and PnL. We will describe procedures for dataset balancing, feature engineering, prompt and response preparation, fine-tuning configuration in Ollama, and reliable parsing. Backtesting and forward testing reveal systematic degradation. The practical conclusion is that the problem must be formulated as a direct optimization of trading outcomes.

We're entering the home stretch. The development of the replay/simulation system is nearly complete. Of course, we still have a few things left to finish, but compared to everything we've already done, completing what's left won't be difficult. However, it is essential to fully absorb and understand everything covered in this article. So I hope you enjoy reading this and, above all, that you enjoy this final stage of the journey.

The article examines two practical aspects of the Adwizard-based optimization pipeline: diagnostics and recovery after failures when generating the final Expert Advisor database, as well as preliminary selection of strategy parameter ranges before project creation. It is shown how analyzing the stages/jobs/tasks tables in SQLite and restarting stages based on their statuses help restore the process, while trial optimization narrows the search space, eliminates redundant parameters, and reduces the risk of getting stuck at local maxima.

In this article, I have shown—in the clearest possible way—how to modify and improve code capable of handling specific tasks while making as few changes as possible to the existing code. We will add a volume display and, at the same time, ensure that users or traders cannot effectively remove objects created by the position indicator.

We consider a BAS+PSO (BSO) hybrid, where BAS provides a local direction signal and PSO facilitates the exchange of best solutions within the swarm. The article presents a mathematical model, pseudocode, an implementation of the class in MQL5, and test results from a standard test bench. This material allows reproducing the algorithm, configuring its parameters, and understanding how three objective-function evaluations per iteration affect efficiency.

In the previous article, we configured the indicator to display the financial result. However, not everyone likes using this display mode. The reasons differ from one trader to another, although in some cases they seem quite reasonable and justified to me. Adapting the code to provide this capability is by no means one of the most difficult tasks. It's actually pretty simple. In this article, we'll look at how to do this.

In this article, we will make the necessary changes so that the position indicator displays the financial result. This way, the trader will be able to get an idea of the financial result of an open position. In addition, I will tell you something that many people do not know, even those who have been using MQL5 for a long time: how to use static variables to share memory and avoid declaring a global variable in the main code.

The article discusses the Colliding Bodies Optimization (CBO) algorithm, which is based on the physics of one-dimensional collisions between bodies. The basic version of the algorithm does not include any configurable parameters, which makes it simple. Therefore, the enhanced ECBO version — supplemented with Colliding Memory and a crossover mechanism — was used as the basis for the implementation, allowing the algorithm to achieve respectable results and earn a place in the ranking table.

In this article, we will implement a number of improvements to ensure that the position indicator accurately reflects the actual state on the trading server in terms of open positions and their current state. I should point out that the applications shown here are in no way intended to replace any of the elements available in MetaTrader 5. They should also not be used without due caution and a balanced approach, since their purpose is to provide educational code—that is, code intended solely for learning how the system works. The reason I call this code “educational” is that, in some cases, using messages is not the best way to implement certain functions.

Debugging is an integral part of the programming cycle. This article discusses common techniques for debugging any application running in the MetaTrader 5 environment.

This second part adds the geometry layer to a Cairo‑inspired graphics library for MetaTrader 5. It defines a path of double‑precision points grouped into contours, records open/closed intent, and stores vertices in a flat array with start indices. We implement MoveTo, LineTo, Close, provide basic shape helpers, and include a demo that visualizes the built geometry for inspection and reuse.