MQL4 EA Learning Module: Diagnosing and Fixing Error 134

//+------------------------------------------------------------------+
//| MQL4 Expert Advisor Learning Module: Diagnosing and Fixing Error 134 |
//+------------------------------------------------------------------+
// Part 1: The Concept - What is Error 134?
/*
Error 134 in MQL4, defined as ERR_TRADE_NOT_ENOUGH_MONEY, occurs when an Expert Advisor (EA) attempts to open a trade but the account lacks sufficient free margin to cover the required margin for the position. This error is logged as, for example, "SendNewOrder::doAction Connot Send Order, error: 134," indicating that the trade request was rejected due to insufficient funds. In the MetaTrader 4 (MT4) environment, free margin is the portion of account equity not currently tied up in open positions, and this error signals that the available free margin is less than what the trade requires.
*/
// Part 2: The "Why" - Diagnosing the Root Causes
/*
Several scenarios can lead to Error 134:
- **Insufficient Free Margin**: The account's free margin is less than the margin required to open the new position. Free margin is calculated as AccountEquity() - AccountMargin(), representing the funds available for new trades.
- **Incorrect Lot Size Calculation**: If the EA uses a fixed or incorrectly calculated lot size that exceeds the account's capacity, it will trigger Error 134. For example, attempting to open a 1-lot trade on a $1,000 account with 1:100 leverage may require $1,000 margin, which could exceed available funds.
- **Leverage Impact**: Leverage determines the margin required per lot. For instance, with 1:100 leverage, a 1-lot trade on EURUSD (100,000 units) typically requires $1,000 margin in the account currency. Lower leverage (e.g., 1:50) doubles the margin requirement, increasing the likelihood of Error 134.
- **Dynamic Spreads & Slippage**: While spreads don’t directly affect margin requirements in standard forex trading, sudden spread widening during volatile market conditions can lead to execution issues, though this is less directly tied to Error 134.
- **Multiple Open Trades**: Each open position consumes margin, reducing the free margin available for new trades. If an EA opens multiple positions without accounting for cumulative margin use, it may exhaust the free margin, causing Error 134.
Understanding these causes is critical for diagnosing and preventing the error in your EA.
*/
// Part 3: The "How" - Proactive Solutions and Code
// Section 3.1: Calculating Required Margin
/*
The following function calculates the margin required for a trade on a given symbol with a specified lot size. It uses MarketInfo(symbol, MODE_MARGINREQUIRED) to obtain the margin needed for one lot and scales it by the desired lot size.
*/
double GetRequiredMargin(string symbol, double lots)
{
    double margin_per_lot = MarketInfo(symbol, MODE_MARGINREQUIRED);
    if (margin_per_lot == 0)
    {
        Print("Failed to get MODE_MARGINREQUIRED for ", symbol);
        return -1; // Indicate an error
    }
    return margin_per_lot * lots;
}
// Section 3.2: Implementing the Safeguard
/*
To prevent Error 134, check the available margin before sending a trade order. MQL4 provides two effective methods:
1. **Using AccountFreeMarginCheck()**: This built-in function returns the free margin that would remain after opening a specified position. A positive value indicates sufficient margin to proceed with the trade.
   Example usage:
*/
void CheckMarginWithFreeMarginCheck(string symbol, int cmd, double lots)
{
    double free_margin_after = AccountFreeMarginCheck(symbol, cmd, lots);
    if (free_margin_after > 0)
    {
        Print("Sufficient margin available. Free margin after trade: ", free_margin_after);
        // Proceed with OrderSend
    }
    else
    {
        Print("Insufficient margin. Free margin after trade would be: ", free_margin_after);
    }
}
/*
2. **Manual Margin Calculation**: Use the GetRequiredMargin() function to calculate the required margin and compare it with AccountFreeMargin().
   Example usage:
*/
void CheckMarginManually(string symbol, double lots)
{
    double required_margin = GetRequiredMargin(symbol, lots);
    if (required_margin > 0 && AccountFreeMargin() > required_margin)
    {
        Print("Sufficient margin. Required: ", required_margin, " Available: ", AccountFreeMargin());
        // Proceed with OrderSend
    }
    else
    {
        if (required_margin <= 0)
            Print("Failed to calculate required margin for ", symbol);
        else
            Print("Insufficient margin. Required: ", required_margin, " Available: ", AccountFreeMargin());
    }
}
// Section 3.3: Practical Code Transformation
/*
Below are "Before" and "After" code examples demonstrating how to transform a vulnerable EA into a robust one by incorporating margin checks.
**Before (Vulnerable Code)**:
This code attempts to open a buy order without checking available margin, risking Error 134.
*/
void VulnerableTradeExample()
{
    double lots = 0.1;
    string symbol = Symbol();
    double ask = MarketInfo(symbol, MODE_ASK);
    
    int ticket = OrderSend(symbol, OP_BUY, lots, ask, 3, 0, 0, "My EA", 0, 0, clrGreen);
    if (ticket < 0)
    {
        Print("OrderSend failed with error #", GetLastError());
    }
}
/*
**After (Robust Code with AccountFreeMarginCheck)**:
This version checks the margin using AccountFreeMarginCheck() before sending the order, preventing Error 134.
*/
void RobustTradeExampleWithFreeMarginCheck()
{
    double lots = 0.1;
    string symbol = Symbol();
    double ask = MarketInfo(symbol, MODE_ASK);
    int cmd = OP_BUY;
    
    double free_margin_after = AccountFreeMarginCheck(symbol, cmd, lots);
    if (free_margin_after > 0)
    {
        int ticket = OrderSend(symbol, cmd, lots, ask, 3, 0, 0, "My EA", 0, 0, clrGreen);
        if (ticket < 0)
        {
            Print("OrderSend failed with error #", GetLastError());
        }
        else
        {
            Print("Trade opened successfully. Ticket: ", ticket);
        }
    }
    else
    {
        Print("Not enough margin to open position. Free margin after trade would be: ", free_margin_after);
    }
}
/*
**After (Robust Code with Manual Margin Calculation)**:
This version uses GetRequiredMargin() to calculate the required margin and compares it with AccountFreeMargin().
*/
void RobustTradeExampleWithManualCheck()
{
    double lots = 0.1;
    string symbol = Symbol();
    double ask = MarketInfo(symbol, MODE_ASK);
    int cmd = OP_BUY;
    
    double required_margin = GetRequiredMargin(symbol, lots);
    if (required_margin > 0 && AccountFreeMargin() > required_margin)
    {
        int ticket = OrderSend(symbol, cmd, lots, ask, 3, 0, 0, "My EA", 0, 0, clrGreen);
        if (ticket < 0)
        {
            Print("OrderSend failed with error #", GetLastError());
        }
        else
        {
            Print("Trade opened successfully. Ticket: ", ticket);
        }
    }
    else
    {
        if (required_margin <= 0)
            Print("Failed to calculate required margin for ", symbol);
        else
            Print("Not enough margin. Required: ", required_margin, " Available: ", AccountFreeMargin());
    }
}
// Part 4: Conclusion - Best Practices for Robust EAs
/*
To build reliable EAs that avoid Error 134, always perform pre-trade margin checks using either AccountFreeMarginCheck() or manual calculations with GetRequiredMargin(). These checks ensure that the EA only attempts trades within the account’s financial capacity, enhancing stability and preventing trade failures. Optionally, consider adding a margin buffer (e.g., requiring AccountFreeMarginCheck() > 100) to account for market volatility or spread changes, though this is typically unnecessary for standard forex trading. The key lesson is to "check before you trade," ensuring your EA operates robustly under varying market and account conditions.
For further reading, refer to the MQL4 documentation:
- AccountFreeMarginCheck: https://docs.mql4.com/account/accountfreemargincheck
- MarketInfo: https://docs.mql4.com/marketinformation/marketinfo
- Error Codes: https://docs.mql4.com/constants/errorswarnings/errorcodes
*/
// Example OnStart function to demonstrate usage
void OnStart()
{
    // Example: Attempt to open a buy order with margin checks
    Print("Testing Vulnerable Trade Example:");
    VulnerableTradeExample();
    
    Print("\nTesting Robust Trade Example with AccountFreeMarginCheck:");
    RobustTradeExampleWithFreeMarginCheck();
    
    Print("\nTesting Robust Trade Example with Manual Margin Check:");
    RobustTradeExampleWithManualCheck();
}

# MQL4 True NRP Indicator Technical Document
## Section 1: Technical Analysis of True NRP Indicators
### Definitions
- **Repainting**: Repainting occurs when an indicator's values, signals, or plots on past (historical) bars change or update in response to new ticks or price data. This typically happens because the indicator incorporates incomplete or evolving data from the current bar, leading to retrospective alterations that can mislead backtesting and trading decisions. For example, a signal arrow that appears or disappears on a closed bar after new data arrives is a classic sign of repainting.
- **True Non-Repainting (NRP)**: A True NRP indicator ensures that all values, signals, and plots associated with closed, historical bars are immutable and fixed once the bar closes. This means that after a bar (e.g., the H1 bar from 10:00 to 11:00) completes at 11:00:01, its indicator output remains unchanged regardless of future price action, ticks, or recalculations. True NRP promotes reliability in analysis by eliminating hindsight bias.
### Core Classification Factors for True NRP
To be classified as True NRP, an MQL4 indicator must strictly adhere to the following mandatory criteria, ensuring no retrospective changes to historical data:
- **Immutability of Historical Data**: All calculations and outputs for any bar index `n` (where `n >= 1`) must be based solely on finalized data from bars `n` and older. No future or incomplete data can influence these values.
- **No Recalculation of Closed Bars**: The indicator must not overwrite or adjust buffer values for closed bars during subsequent ticks or bar formations. Buffers should be populated once per bar and preserved.
- **Absence of Look-Ahead Bias**: Logic must avoid using data from bars newer than the one being processed (e.g., no forward-shifting in loops or functions like `iHighest` with ranges extending into "future" bars).
- **Signal Persistence**: Any generated signals (e.g., arrows, alerts) must be tied to closed bars and not removable or modifiable post-generation.
- **Bar Indexing**: A critical rule for True NRP is that valid signals must be generated and confirmed *only* on a fully closed bar, typically by checking conditions on `bar[1]` (the most recently closed bar). This ensures the signal uses complete, unchanging OHLC data. Signals on the current, unclosed bar (`bar[0]`) are inherently repainting because `bar[0]`'s data (e.g., Close[0], High[0]) evolves with each tick until closure. For instance, a condition like `Close[0] > Open[0]` may trigger falsely intra-bar and then reverse, causing the signal to "repaint" when viewed historically.
- **Data Source Integrity**: Using future data, such as higher timeframe (HTF) data without proper bar synchronization, leads to repainting because HTF bars may not align with the current chart's bar closure. For example, referencing an unclosed HTF bar can introduce mutable data that alters past calculations on the lower timeframe. To maintain integrity, synchronize data access to ensure only closed HTF bars are used (e.g., via `iBarShift` to align timestamps).
- **Static vs. Dynamic Calculations**: Static calculations are fixed once a bar closes, relying only on historical data up to that point (e.g., a simple moving average computed up to `bar[1]`). Dynamic calculations, which can be influenced by subsequent price action (e.g., adaptive filters that smooth past values based on new ticks), lead to repainting. True NRP favors static calculations to ensure outputs are deterministic and unchanging for closed bars.
### Recommended MQL4 Logic for True NRP Behavior
To achieve True NRP, structure the indicator with a two-loop approach: one for calculating values using only closed bars, and another for displaying signals based on those calculations. This separates concerns and prevents repainting. Always include a new bar check to process logic only once per bar formation.
Below are commented MQL4 code snippets demonstrating correct signal generation logic.
**Snippet 1: Robust New Bar Check and Signal on bar[1]**  
This ensures the signal triggers only once per new bar and checks conditions on the closed `bar[1]`.
```mql4
// In global scope
datetime prevTime = 0;
// In start() or OnCalculate()
int start() {
    // Robust check: Trigger only on new bar formation
    if (Time[0] == prevTime) return(0);  // Skip if not a new bar
    prevTime = Time[0];  // Update for next check
    
    // Example: Calculate values (Loop 1 - Static calculation on closed bars)
    double maFast = iMA(NULL, 0, 5, 0, MODE_SMA, PRICE_CLOSE, 1);  // Use shift 1 for closed bar
    double maSlow = iMA(NULL, 0, 20, 0, MODE_SMA, PRICE_CLOSE, 1); // Use shift 1
    
    // Display signal (Loop 2 - Based on closed bar data)
    if (maFast > maSlow) {
        // Generate buy signal on closed bar[1] - immutable
        ObjectCreate("BuyArrow", OBJ_ARROW, 0, Time[1], Low[1] - 10 * Point);
    }
    
    return(0);
}
```
**Snippet 2: Accessing Custom Indicator Values from bar[1]**  
This shows how to use `iCustom` to fetch values from another indicator, shifted to the closed bar.
```mql4
// In start() or OnCalculate(), after new bar check
double customValue = iCustom(NULL, 0, "MyCustomIndicator", /* params */, 0, 1);  // Buffer 0, shift 1 (closed bar)
double prevCustomValue = iCustom(NULL, 0, "MyCustomIndicator", /* params */, 0, 2);  // For crossover check
if (customValue > 50 && prevCustomValue <= 50) {
    // Signal on closed bar[1] using confirmed data
    Alert("Buy Signal on closed bar");
}
```
These snippets ensure signals are static and non-repainting by relying on closed bar data.
## Section 2: Workflow Guide to Convert an Indicator to True NRP
This workflow guides programmers through analyzing and converting a potentially repainting MQL4 indicator into a True NRP version. Follow these steps sequentially, using MetaEditor for code changes and MT4 for testing.
### 1. Code Audit
- Open the `.mq4` file in MetaEditor and locate the main calculation function: `start()` (for older MQL4) or `OnCalculate()` (for newer builds).
- Identify signal generation logic by searching for keywords like `if`, `ObjectCreate`, `Alert`, `Buffer[i] =`, or custom functions that plot arrows/lines. Note where conditions check price data (e.g., `Close[]`, `High[]`).
- Pinpoint look-ahead variables or checks against `bar[0]`: Use find/replace to highlight `[0]`, `shift=0`, or functions like `iMA(...,0)`. Also, check loops that iterate from 0 (including current bar) or use future shifts (e.g., `i+1` in a backward loop). Flag any HTF data access without synchronization.
### 2. Logic Isolation
- Isolate the core trading condition: Extract the primary `if` statement or calculation that determines signals (e.g., "if (fastMA > slowMA)"). Document it separately.
- Trace dependencies: Follow variables back to their sources to ensure no mutable data (e.g., from `bar[0]`) influences the condition. If HTF data is used, verify alignment with closed bars using `iBarShift`.
- Comment the isolated logic in the code (e.g., `// Core condition: fastMA[1] > slowMA[1]`).
### 3. NRP Refactoring
- Restructure to use a two-loop approach: Calculate static values first, then display based on closed bars.
- Add a new bar check and shift conditions from `bar[0]` to `bar[1]`.
**Before (Repainting) Example**: Signals on unclosed `bar[0]`, prone to changes.
```mql4
int start() {
    double maFast = iMA(NULL, 0, 5, 0, MODE_SMA, PRICE_CLOSE, 0);  // Uses bar[0]
    double maSlow = iMA(NULL, 0, 20, 0, MODE_SMA, PRICE_CLOSE, 0);
    
    if (maFast > maSlow) {
        ObjectCreate("BuyArrow", OBJ_ARROW, 0, Time[0], Low[0]);  // Repaints as bar[0] evolves
    }
    return(0);
}
```
**After (True NRP) Example**: Adds new bar check and shifts to `bar[1]`.
```mql4
datetime prevTime = 0;
int start() {
    // New bar check: Process only once per bar
    if (Time[0] == prevTime) return(0);
    prevTime = Time[0];
    
    // Loop 1: Calculate static values on closed bars
    double maFast = iMA(NULL, 0, 5, 0, MODE_SMA, PRICE_CLOSE, 1);  // Shifted to bar[1]
    double maSlow = iMA(NULL, 0, 20, 0, MODE_SMA, PRICE_CLOSE, 1);
    double prevMaFast = iMA(NULL, 0, 5, 0, MODE_SMA, PRICE_CLOSE, 2);  // For crossover
    double prevMaSlow = iMA(NULL, 0, 20, 0, MODE_SMA, PRICE_CLOSE, 2);
    
    // Loop 2: Display signal on closed bar
    if (maFast > maSlow && prevMaFast <= prevMaSlow) {
        ObjectCreate("BuyArrow", OBJ_ARROW, 0, Time[1], Low[1]);  // Immutable on bar[1]
    }
    return(0);
}
```
### 4. Validation
- Compile the refactored indicator and attach it to a chart in MT4.
- Use the Strategy Tester in visual mode: Select a symbol/timeframe, enable visual mode, and run a backtest. Pause and step through bars (using the pause button or F12 for single-step).
- Confirm fixes: Observe signals on historical bars as new bars form; ensure past signals do not change, move, or disappear. Compare with the original version to verify immutability.
- Test edge cases: Run on weekends (gaps), low-volume periods, or reload the chart to check for recalculation issues. If repainting persists, revisit the audit and refactor iteratively.

Quoting MwlRCT

Disliked

//+------------------------------------------------------------------+ //| MQL4 Expert Advisor Learning Module: Diagnosing and Fixing Error 134 | //+------------------------------------------------------------------+ // Part 1: The Concept - What is Error 134? /* Error 134 in MQL4, defined as ERR_TRADE_NOT_ENOUGH_MONEY, occurs when an Expert Advisor (EA) attempts to open a trade but the account lacks sufficient free margin to cover the required margin for the position. This error is logged as, for example, "SendNewOrder::doAction Connot Send Order,...

Ignored