iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
OrderSend() returning true does not confirm that a position opened. It means the request passed initial checks and was accepted for processing. To find out what happened, check the server return code, follow the order and deal through the trade lifecycle, then confirm the position in account state before managing it.
1. Check the server result code
Keep the Boolean return and the server response separate. OrderSend() takes a MqlTradeRequest and a MqlTradeResult. Its return value reports that the request passed basic checks and was accepted for further processing; execution may happen later. For a market request (TRADE_ACTION_DEAL), a successful function return alone does not mean the trade was executed, as the MQL5 Reference explains.
Inspect result.retcode to learn the trade server’s response. Log result.comment and, when an external trading system’s response matters, result.retcode_external. External return-code meanings can depend on the broker or system, so do not assume that a value has the same interpretation everywhere. The fields are documented in the MqlTradeResult reference.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall| Return code | Meaning | What it tells you |
|---|---|---|
TRADE_RETCODE_PLACED (10008) |
Order placed | An order was placed; this does not by itself confirm that a position exists. |
TRADE_RETCODE_DONE (10009) |
Request completed | The request completed; verify the resulting account state for the position your EA expects. |
TRADE_RETCODE_DONE_PARTIAL (10010) |
Request completed partially | Only part of the request completed, so the resulting exposure may differ from the requested volume. |
These are MQL5 API return-code constants, not a universal retry policy. Interpret the code in the context of the requested operation; retrying every non-success outcome can repeat an invalid request or create duplicate actions. See the full trade server return-code list.
2. Follow the order, deal, and position lifecycle
An order, a deal, and a position are different objects. In the MQL5 Reference’s market-buy example, the lifecycle includes order creation, execution, removal from the open-order list, transfer to order history, a deal added to deal history, and creation of a position. One request can generate several trade-transaction events, and those events may arrive after the initial call returns.
Do not treat result.order or result.deal as a position confirmation. The result structure defines deal as a deal ticket when a deal was performed and order as an order ticket when one was placed; an order ticket is especially relevant when placing a pending order. Check the fields against the operation you sent, using the result structure documentation.
Use trade events or query fresh state
For follow-up, correlate progress in OnTradeTransaction() or query the account after processing advances. The callback can be invoked for multiple transactions related to one request. It receives request and result information for request-type transactions; do not expect those parameters to describe every transaction type. The transaction-type reference and the MQL5 book’s section on OrderSend and OrderSendAsync describe these event paths.
When you query current orders, deal history, and positions, look for the state that matches the action you requested. A pending order can exist without an open position; a completed deal may have created, increased, reduced, or otherwise changed exposure depending on the account state and operation. The initial return value alone cannot settle which state applies.
Use OrderCheck only as a preflight
OrderCheck() can validate a request before sending it and return check results, including projected account and margin information. It does not guarantee that a later request will be filled. Treat it as a preflight check, not an execution confirmation; see the OrderCheck reference.
3. Use the right position identifier when managing exposure
When closing or modifying a position, set MqlTradeRequest.position appropriately. The required identifier depends on the account’s position mode. In hedging mode, specify the position ticket. In netting mode, the symbol identifies the position, although the ticket can also be set. These request fields are described in the MqlTradeRequest reference.
Rank #4
This is a separate check from confirming execution: a valid order or deal does not ensure that a later close or modification targets the intended position. Read the account mode and use the corresponding identifier when constructing the follow-up request.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsQuick Recap
Apply the checks to your EA
- Separate acceptance from outcome. After
OrderSend(request, result), handle a false function return as an initial request problem. If it returns true, inspectresult.retcode; logresult.commentand relevant result fields, includingretcode_externalwhen applicable. - Resolve the lifecycle. Interpret
result.orderandresult.dealaccording to the operation, then useOnTradeTransaction()or fresh order, deal-history, and position queries to establish what actually happened. - Target the resulting position correctly. For a close or modification request, populate
request.positionaccording to hedging or netting mode.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
