I've been down the rabbit hole enough times to know that the most frustrating bugs aren't in your code, they're in the stuff the manual doesn't tell you. Let me share two discoveries that cost me days of debugging, and they're not the usual "did you enable DLL imports" type of advice.
The Market Watch Ghost Symbols
You've got your EA scanning 5 pairs in the Market Watch. It opens trades, manages them, everything's fine. Then you check back an hour later and suddenly it's trading 8 pairs. Or 29. Or every single symbol your broker offers.
This isn't a bug. It's a feature. An undocumented one.
Here's what's actually happening, confirmed by MetaQuotes staff on the MQL5 forum: when your EA scans symbols in Market Watch and opens positions, MT4 silently adds any currency pair involved in calculating margin or profit back into the Market Watch list . If your EA references EURUSD to calculate something, that pair gets implicitly included. Next scan cycle, your EA sees more symbols, opens more positions, adds more symbols, and the cycle spirals.
The official explanation from stringo (MetaQuotes developer) was: "This behaviour was present long before we updated MQL4. Namely, implicit inclusion of pairs that participate in calculation of profits and margin requirements (if they weren't included before)" . They acknowledged it's undocumented and suggested adding a way to know if a symbol is hidden, but never actually changed the behavior.
My workaround: Before running any EA that scans Market Watch, manually remove every symbol you don't want traded. And I mean every single one. Then in your EA initialization, explicitly set which symbols to monitor using
SymbolSelect() with false for unwanted pairs. Do this in OnInit() so it runs once, not on every tick. If you're running multiple EAs on the same terminal, put each one on its own chart with its own symbol list and use magic numbers religiously.The 0 and 1 Truth Bomb
Here's something that tripped me up early on and I still see it in other people's code. In MQL4/MQL5, the if statement doesn't treat all non-zero values as true. Actually, wait - it does. But the critical detail is what happens when you're dealing with function returns.
Let's run a quick mental test:
if(1) returns true. if(2) returns true. if(-1) returns true. if(0.1) returns true. Only 0 is false . Every single other numeric value, positive or negative, decimal or integer, evaluates to true.Now, why does this matter in practice?
Take
OrderSend(). If it fails, it returns -1. A rookie mistake is writing if(OrderSend(...)) assuming a failed order sends 0. It doesn't. -1 evaluates to true, so your EA thinks the order succeeded and continues executing code that should only run after a successful open. This has caused more unintended positions than I care to count.The safe pattern:
``
cpp
int ticket = OrderSend(...);
if(ticket < 0) {
// It failed. Handle it.
Print("Order failed. Error: ", GetLastError());
} else {
// It succeeded. Proceed.
// ...manage the order...
}
`
Always test against for functions that return -1 on failure . Or test against > 0 if that's the success indicator. Don't use the function call directly inside the if condition unless you're absolutely certain about what it returns on failure.
One More: The OrderSend and OrderModify Timing Trap
This one's a classic in EA programming. You open a market order without SL/TP, then immediately call OrderModify() to add them. Sounds reasonable, right?
Problem: between OrderSend() returning and OrderModify() executing, the market price can move. Your calculated stop loss might become invalid (e.g., a buy stop below current price), and OrderModify() fails silently . Your EA thinks the position has protection, but it's actually running naked.
The fix: Send SL and TP directly in the OrderSend()` call. One atomic operation, no race condition. If the order fails, you catch it immediately. If it succeeds, it has the intended protection from the start.---
Reference:
本文首发于FXEAR.com，原创内容，未经授权禁止转载