Object-Oriented Classes for Managing Pending Trading Requests in MQL5
Summary
This article refactors pending trade requests into an extensible object model for an MQL5 trading library. A shared abstract base object holds properties common to requests, while six specialized descendants represent opening or closing positions, modifying position stops, placing or removing pending orders, and changing pending-order parameters. The requests may originate from server errors that require a delayed retry, or from conditions such as a price level or symbol-property threshold being reached.
The discussion covers request statuses, types, identifiers, timing, retry counts, and fields drawn from trade-request data. It also explains why separating common and operation-specific properties supports reuse and extension across the library. The article is a software design and implementation installment, not a trading strategy or empirical evaluation. It provides no evidence that retrying requests improves trading outcomes; correctness and behavior depend on the surrounding trading class and platform handling.
Key ideas
- A pending trading request can delay order submission until a retry condition or market condition is met.
- A shared abstract class stores properties common to all pending requests.
- Specialized child classes represent six operation types, including position changes and pending-order management.
- Request objects track status, origin, identifiers, timing, attempts, and trade parameters.
- The article presents a library architecture rather than evidence of trading performance.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.