forex-scalping.com

Posted: **Mon Sep 21, 2026 9:44 pm**

The Kelly Criterion and Why Most Traders Shouldn't Use It Directly

The Kelly Criterion, a formula originally developed for optimizing bet sizing in a mathematically well-defined context, gets referenced frequently in trading circles as a theoretically optimal position sizing approach — worth understanding both for its genuine mathematical insight and for the specific, practical reasons most scalpers shouldn't apply it directly and unmodified.

What the Kelly Criterion Mathematically Calculates

The formula calculates the theoretically optimal fraction of capital to risk on a given bet or trade, based specifically on the probability of winning and the payout ratio, designed to maximize long-run geometric growth rate — connecting directly to the risk-of-ruin discussion in the previous post, the Kelly Criterion represents one specific, mathematically-derived answer to the same underlying question that risk-of-ruin calculation addresses from a different angle.

Why the Kelly Criterion's Pure, Unmodified Output Tends to Recommend Position Sizes Too Aggressive for Practical Trading

A critical, often-overlooked feature of the Kelly Criterion: it assumes your win-rate and payout-ratio inputs are known with genuine precision and certainty — in actual trading, these figures are estimates drawn from historical data (per the backtesting and journaling discipline covered throughout this series) that carry genuine uncertainty and can shift as market conditions evolve, meaning the pure, mathematically "optimal" Kelly-calculated position size, based on necessarily imperfect estimates, tends to recommend considerably more aggressive sizing than a prudent trader should actually risk given this genuine estimation uncertainty.

The Common Practical Adjustment: Fractional Kelly

Many practitioners who do use Kelly-based sizing apply a "fractional Kelly" approach — deliberately risking only a fraction (commonly a quarter to a half) of the full, mathematically-calculated Kelly recommendation, specifically to account for the estimation uncertainty covered above and to reduce the very real volatility the full Kelly calculation can produce even when its underlying assumptions are genuinely accurate, connecting directly to the earlier position sizing formulas post's general recommendation toward modest, consistent per-trade risk.

Why the More Straightforward Fixed-Percentage Approach Covered Earlier in This Series Remains More Practical for Most Scalpers

Given the genuine estimation uncertainty problem, and given scalping's high trade frequency (meaning even modest position-sizing errors compound rapidly across many trades, connecting to the earlier risk-of-ruin discussion), the simpler, fixed-percentage position sizing approach covered in the earlier position sizing formulas post — combined with periodic risk-of-ruin recalculation per the previous post — generally offers a more practical, robust approach for most scalpers than attempting to precisely calculate and apply even a fractional Kelly figure based on inherently uncertain, evolving win-rate and payout-ratio estimates.

Where Kelly Thinking Still Offers Genuine, Practical Value Even Without Precise Formula Application

Beyond the precise formula itself, the Kelly Criterion's underlying logic — that optimal position sizing depends directly on the specific combination of win rate and payout ratio, and that sizing too aggressively relative to these figures mathematically damages long-run growth even when the underlying strategy has genuine edge — reinforces the same core principle this series has emphasized throughout via the position sizing formulas and risk-of-ruin discussions, even for traders who don't apply the precise Kelly formula directly.

The Underlying Point

The Kelly Criterion offers genuine, valuable mathematical insight into the relationship between win rate, payout ratio, and optimal position sizing, but its pure, unmodified output tends to recommend more aggressive sizing than prudent given the genuine estimation uncertainty inherent in real trading statistics — most scalpers are better served by the simpler, fixed-percentage position sizing approach covered earlier in this series, informed by the same underlying logic Kelly formalizes, rather than by attempting to precisely calculate and apply the formula itself.

Posted: **Mon Sep 21, 2026 9:50 pm**

Building an Expectancy Formula for Your Own Strategy

Expectancy — the average amount a strategy can be expected to win or lose per trade over a large sample — has been referenced throughout this series in the risk-to-reward math and journaling discussions, but building and actually calculating this specific figure for your own strategy deserves direct, practical treatment.

The Basic Expectancy Formula

Expectancy is calculated as: (Win rate × Average win size) minus (Loss rate × Average loss size) — this produces a single figure representing the average expected outcome per trade, in either pips, dollars, or R-multiples (risk units), directly synthesizing the win-rate and risk-to-reward inputs the earlier risk-to-reward math post discussed more conceptually into one concrete, calculable number.

Why Calculating This Figure Precisely for Your Own Strategy Matters More Than General Guidelines

Connecting directly to the extensive journaling discipline covered throughout this series, your own actual, tracked win rate and average win/loss sizes — not generic, commonly-cited industry figures — should feed this calculation, since expectancy is fundamentally a property of your specific strategy, executed by you, under your specific conditions, rather than a universal constant that transfers cleanly from general trading advice or other traders' reported statistics.

A Worked Example Using Realistic Figures

A strategy with a 40% win rate, average winning trade of 2R (twice the risked amount), and average losing trade of 1R (the full risked amount, assuming stops are respected per the discipline covered throughout this series) produces an expectancy of (0.40 × 2R) minus (0.60 × 1R), equaling 0.8R minus 0.6R, or a positive expectancy of 0.2R per trade — meaning, over a large sample, this strategy would be expected to average a 0.2R gain per trade, a genuinely modest but real, positive edge worth understanding precisely rather than only intuitively.

Why This Precise Figure Directly Informs the Risk-of-Ruin and Kelly Discussions Covered in the Previous Posts

Your calculated expectancy figure, combined with your trade frequency, directly determines your strategy's overall growth potential and, combined with the risk-of-ruin calculation covered earlier, your appropriate position sizing — a strategy with only modestly positive expectancy (like the 0.2R example above) genuinely can still be profitable and worth trading, but likely warrants more conservative position sizing than a strategy with considerably higher calculated expectancy, directly connecting this specific number to the practical sizing decisions covered throughout this series.

Why Recalculating Expectancy Periodically, Rather Than Once, Matters

Similar to the periodic risk-of-ruin recalculation recommended in the earlier post, expectancy should be recalculated periodically using updated, current journal data rather than treated as a single, permanently fixed figure — connecting to the compression-expansion cycle and broader market-condition-variation discussions covered throughout this series, your strategy's actual expectancy can genuinely shift somewhat as market conditions evolve, and periodic recalculation ensures your understanding of your own edge remains current rather than based on outdated, earlier data.

The Underlying Point

Calculating your own strategy's precise expectancy figure, using your own actual tracked win rate and win/loss sizes rather than generic industry benchmarks, synthesizes the risk-to-reward and journaling disciplines covered throughout this series into one concrete, actionable number — directly informing the position sizing and risk-of-ruin calculations covered in the surrounding posts, and worth recalculating periodically as your own tracked statistics continue to accumulate and evolve over time.

Posted: **Mon Sep 21, 2026 9:58 pm**

Grading Your Trades: A Letter-System Approach to Self-Review

Beyond the structured journal fields covered extensively throughout this series (setup type, confluence score, planned versus realized risk-to-reward), a simple letter-grading system for each trade offers a genuinely useful, fast, holistic complement to the more granular metrics already discussed — worth considering as an addition to your existing journaling practice.

Why a Simple Grade Adds Value Beyond the Granular Metrics Already Covered

The detailed, itemized journal fields covered throughout this series provide genuinely valuable, specific data, but reviewing dozens of individual data points across many trades can make it harder to quickly recall or communicate an overall, holistic sense of how well a given trade was actually executed — a simple letter grade (A through F, or a similar scale) provides a fast, memorable, at-a-glance summary that complements rather than replaces the more granular data.

A Practical Grading Framework Tied Directly to Process, Not Outcome

Consistent with the process-over-outcome evaluation this series has emphasized throughout, grades should be assigned based on criteria adherence and execution quality, not on whether the trade ultimately won or lost — an A-grade trade is one that met your full confluence checklist, was sized correctly, and was managed according to plan, regardless of outcome; an F-grade trade is one that violated multiple criteria, regardless of whether it happened to win anyway (directly connecting to the "why winning trades can be dangerous" discussion covered earlier in this series).

Why This Framework Specifically Helps Counter Several Biases Covered Earlier in This Batch

A strict, process-based grading discipline provides a direct, structural safeguard against the self-serving bias covered earlier in this batch — grading a trade honestly based on process, independent of outcome, forces the same symmetric evaluation that post recommended as the practical defense against that specific bias, giving it a concrete, simple, repeatable format rather than leaving that symmetric evaluation as an abstract intention.

A Practical Use for Aggregated Grade Data Over Time

Beyond individual trade review, tracking your grade distribution over time — what percentage of trades earn an A or B versus a D or F — provides a simple, easily-trackable proxy for overall discipline trend, directly supporting the specific, stage-appropriate goals covered in the earlier "first six months" roadmap and the monthly goal-setting discussion covered earlier in this series, without requiring the more detailed statistical analysis those more granular metrics demand for a similar, high-level discipline check.

Why This System Works Particularly Well for Scalping's High Trade Frequency

Given scalping's considerably higher trade frequency compared to longer-duration trading styles, a fast, simple grading system that can be applied quickly after each trade — without requiring the full, detailed journal entry for every single trade in real time — helps maintain the review discipline this series has emphasized throughout even during a busy, high-frequency session, with the more detailed, granular journal fields reserved for a subset of particularly instructive trades (both strong and weak) during the more thorough, periodic review this series has recommended throughout.

The Underlying Point

A simple, process-based letter-grading system offers a fast, memorable complement to the more detailed journal metrics covered throughout this series — providing an easily-trackable discipline trend indicator, reinforcing the process-over-outcome evaluation this series has emphasized throughout, and offering a practical way to maintain review discipline even during scalping's characteristically high trade frequency without requiring exhaustive detail on every single trade.

Posted: **Mon Sep 21, 2026 10:05 pm**

Fairman wrote: Mon Sep 21, 2026 9:58 pm Grading Your Trades: A Letter-System Approach to Self-Review

Beyond the structured journal fields covered extensively throughout this series (setup type, confluence score, planned versus realized risk-to-reward), a simple letter-grading system for each trade offers a genuinely useful, fast, holistic complement to the more granular metrics already discussed — worth considering as an addition to your existing journaling practice.

Why a Simple Grade Adds Value Beyond the Granular Metrics Already Covered

The detailed, itemized journal fields covered throughout this series provide genuinely valuable, specific data, but reviewing dozens of individual data points across many trades can make it harder to quickly recall or communicate an overall, holistic sense of how well a given trade was actually executed — a simple letter grade (A through F, or a similar scale) provides a fast, memorable, at-a-glance summary that complements rather than replaces the more granular data.

A Practical Grading Framework Tied Directly to Process, Not Outcome

Consistent with the process-over-outcome evaluation this series has emphasized throughout, grades should be assigned based on criteria adherence and execution quality, not on whether the trade ultimately won or lost — an A-grade trade is one that met your full confluence checklist, was sized correctly, and was managed according to plan, regardless of outcome; an F-grade trade is one that violated multiple criteria, regardless of whether it happened to win anyway (directly connecting to the "why winning trades can be dangerous" discussion covered earlier in this series).

Why This Framework Specifically Helps Counter Several Biases Covered Earlier in This Batch

A strict, process-based grading discipline provides a direct, structural safeguard against the self-serving bias covered earlier in this batch — grading a trade honestly based on process, independent of outcome, forces the same symmetric evaluation that post recommended as the practical defense against that specific bias, giving it a concrete, simple, repeatable format rather than leaving that symmetric evaluation as an abstract intention.

A Practical Use for Aggregated Grade Data Over Time

Beyond individual trade review, tracking your grade distribution over time — what percentage of trades earn an A or B versus a D or F — provides a simple, easily-trackable proxy for overall discipline trend, directly supporting the specific, stage-appropriate goals covered in the earlier "first six months" roadmap and the monthly goal-setting discussion covered earlier in this series, without requiring the more detailed statistical analysis those more granular metrics demand for a similar, high-level discipline check.

Why This System Works Particularly Well for Scalping's High Trade Frequency

Given scalping's considerably higher trade frequency compared to longer-duration trading styles, a fast, simple grading system that can be applied quickly after each trade — without requiring the full, detailed journal entry for every single trade in real time — helps maintain the review discipline this series has emphasized throughout even during a busy, high-frequency session, with the more detailed, granular journal fields reserved for a subset of particularly instructive trades (both strong and weak) during the more thorough, periodic review this series has recommended throughout.

The Underlying Point

A simple, process-based letter-grading system offers a fast, memorable complement to the more detailed journal metrics covered throughout this series — providing an easily-trackable discipline trend indicator, reinforcing the process-over-outcome evaluation this series has emphasized throughout, and offering a practical way to maintain review discipline even during scalping's characteristically high trade frequency without requiring exhaustive detail on every single trade.

Hi Fairman,

This is an excellent framework. When scalping price action on the 1-minute and 5-minute charts, the sheer volume of setups makes extensive mid-session journaling a distraction. A rapid A-F grading system bridges the gap perfectly—it forces immediate accountability for execution mechanics (like waiting for the proper liquidity sweep) without bogged-down data entry. By decoupling the grade from the PnL outcome, it neutralizes outcome bias right at the source.

To make the aggregated data actionable, I put together a Pine Script dashboard. Instead of tracking this in a separate spreadsheet, you can input your session grades directly into the indicator settings. It renders a clean, real-time HUD on your TradingView chart so you can monitor your discipline trend and A/B vs D/F percentage while you trade.

Posted: **Mon Sep 21, 2026 10:06 pm**

PineScript:

Code: Select all

//@version=5
indicator("Trade Grade Distribution Dashboard", overlay=true)

// User inputs for session or weekly grade tallies
grade_A = input.int(0, title="Grade A (Perfect Process)", minval=0, group="Session Grade Log")
grade_B = input.int(0, title="Grade B (Minor Infraction)", minval=0, group="Session Grade Log")
grade_C = input.int(0, title="Grade C (Marginal/Rushed)", minval=0, group="Session Grade Log")
grade_D = input.int(0, title="Grade D (Poor Discipline)", minval=0, group="Session Grade Log")
grade_F = input.int(0, title="Grade F (Total Rule Break)", minval=0, group="Session Grade Log")

// Calculate totals and percentages
totalTrades = grade_A + grade_B + grade_C + grade_D + grade_F

pct_A = totalTrades > 0 ? (grade_A / totalTrades) * 100 : 0
pct_B = totalTrades > 0 ? (grade_B / totalTrades) * 100 : 0
pct_C = totalTrades > 0 ? (grade_C / totalTrades) * 100 : 0
pct_D = totalTrades > 0 ? (grade_D / totalTrades) * 100 : 0
pct_F = totalTrades > 0 ? (grade_F / totalTrades) * 100 : 0

// Table rendering setup
var table gradeTable = table.new(position.bottom_right, 3, 6, bgcolor=color.new(color.black, 80), border_width=1, border_color=color.new(color.gray, 80))

// Populate table on the last bar to optimize performance
if barstate.islast
    // Headers
    table.cell(gradeTable, 0, 0, "Grade", text_color=color.white, text_halign=text.align_left, bgcolor=color.new(color.blue, 70))
    table.cell(gradeTable, 1, 0, "Count", text_color=color.white, text_halign=text.align_center, bgcolor=color.new(color.blue, 70))
    table.cell(gradeTable, 2, 0, "%", text_color=color.white, text_halign=text.align_right, bgcolor=color.new(color.blue, 70))
    
    // Row A
    table.cell(gradeTable, 0, 1, "A (Excellent)", text_color=color.new(color.green, 0), text_halign=text.align_left)
    table.cell(gradeTable, 1, 1, str.tostring(grade_A), text_color=color.white, text_halign=text.align_center)
    table.cell(gradeTable, 2, 1, str.tostring(pct_A, "#.1") + "%", text_color=color.white, text_halign=text.align_right)
    
    // Row B
    table.cell(gradeTable, 0, 2, "B (Good)", text_color=color.new(color.teal, 0), text_halign=text.align_left)
    table.cell(gradeTable, 1, 2, str.tostring(grade_B), text_color=color.white, text_halign=text.align_center)
    table.cell(gradeTable, 2, 2, str.tostring(pct_B, "#.1") + "%", text_color=color.white, text_halign=text.align_right)

    // Row C
    table.cell(gradeTable, 0, 3, "C (Marginal)", text_color=color.new(color.yellow, 0), text_halign=text.align_left)
    table.cell(gradeTable, 1, 3, str.tostring(grade_C), text_color=color.white, text_halign=text.align_center)
    table.cell(gradeTable, 2, 3, str.tostring(pct_C, "#.1") + "%", text_color=color.white, text_halign=text.align_right)

    // Row D
    table.cell(gradeTable, 0, 4, "D (Poor)", text_color=color.new(color.orange, 0), text_halign=text.align_left)
    table.cell(gradeTable, 1, 4, str.tostring(grade_D), text_color=color.white, text_halign=text.align_center)
    table.cell(gradeTable, 2, 4, str.tostring(pct_D, "#.1") + "%", text_color=color.white, text_halign=text.align_right)

    // Row F
    table.cell(gradeTable, 0, 5, "F (Fail)", text_color=color.new(color.red, 0), text_halign=text.align_left)
    table.cell(gradeTable, 1, 5, str.tostring(grade_F), text_color=color.white, text_halign=text.align_center)
    table.cell(gradeTable, 2, 5, str.tostring(pct_F, "#.1") + "%", text_color=color.white, text_halign=text.align_right)

Posted: **Mon Sep 21, 2026 10:06 pm**

To elevate this to a professional standard, we need to treat the tracking with the same strict modularity and architectural rigor you would expect in a well-structured backend environment.

This upgraded iteration moves away from a basic tally and introduces a Weighted Discipline Index (WDI)—effectively a GPA for your execution. It is refactored using Pine Script v5 User-Defined Types (UDTs) to encapsulate the data logically, making the codebase scalable and modular.

Visually, it drops the clunky borders for a minimalist, dynamic heads-up display. It changes color based on your overall execution health, ensuring it stays entirely out of the way when analyzing raw price action and candlestick structures on your daily or 15-minute charts.

Posted: **Mon Sep 21, 2026 10:07 pm**

Here is the professional-grade implementation:

Code: Select all

//@version=5
indicator("Systematic Execution Grading Matrix", overlay=true, display=display.none)

// ============================================================================
// SYSTEM ARCHITECTURE: User-Defined Types (UDTs)
// ============================================================================
type GradeMetrics
    string  label
    int     count
    float   weight
    color   theme

// ============================================================================
// INPUT PARAMETERS (Session / Weekly Log)
// ============================================================================
var string G_LOG = "Execution Grading Log"
int inp_A = input.int(0, "Grade A (Perfect Process)", minval=0, group=G_LOG, inline="A", tooltip="Flawless adherence to confluence checklist.")
int inp_B = input.int(0, "Grade B (Minor Infraction)", minval=0, group=G_LOG, inline="B", tooltip="Slight timing/sizing error, but overall process followed.")
int inp_C = input.int(0, "Grade C (Marginal)", minval=0, group=G_LOG, inline="C", tooltip="Forced setup, chased price, or premature exit.")
int inp_D = input.int(0, "Grade D (Poor)", minval=0, group=G_LOG, inline="D", tooltip="Severe rule violation, emotional execution.")
int inp_F = input.int(0, "Grade F (Total Failure)", minval=0, group=G_LOG, inline="F", tooltip="Complete loss of discipline, moving stops, revenge trading.")

string ui_position = input.string("Bottom Right", "Dashboard Position", options=["Top Right", "Bottom Right", "Bottom Left"], group="UI / UX Settings")

// ============================================================================
// LOGIC & CALCULATIONS
// ============================================================================
int totalTrades = inp_A + inp_B + inp_C + inp_D + inp_F

// Weighted Discipline Index (GPA style: A=4, B=3, C=2, D=1, F=0)
float totalScore = (inp_A * 4) + (inp_B * 3) + (inp_C * 2) + (inp_D * 1) + (inp_F * 0)
float maxPossibleScore = totalTrades * 4
float disciplineIndex = totalTrades > 0 ? (totalScore / maxPossibleScore) * 100 : 0

// Dynamic UI color based on execution health
color indexColor = disciplineIndex >= 85 ? color.new(#00E676, 10) : 
                   disciplineIndex >= 70 ? color.new(#FFD600, 10) : 
                   color.new(#FF5252, 10)

// Initialize data objects
GradeMetrics gradeA = GradeMetrics.new("A (Perfect)", inp_A, 0.0, color.new(#00E676, 0))
GradeMetrics gradeB = GradeMetrics.new("B (Acceptable)", inp_B, 0.0, color.new(#69F0AE, 20))
GradeMetrics gradeC = GradeMetrics.new("C (Marginal)", inp_C, 0.0, color.new(#FFD600, 0))
GradeMetrics gradeD = GradeMetrics.new("D (Poor)", inp_D, 0.0, color.new(#FF6D00, 0))
GradeMetrics gradeF = GradeMetrics.new("F (Failure)", inp_F, 0.0, color.new(#FF5252, 0))

// Array formulation for iterative rendering
array<GradeMetrics> gradeArray = array.from(gradeA, gradeB, gradeC, gradeD, gradeF)

// Percentage calculations
if totalTrades > 0
    for i = 0 to array.size(gradeArray) - 1
        GradeMetrics current = array.get(gradeArray, i)
        current.weight := (current.count / totalTrades) * 100

// ============================================================================
// UI RENDERING ENGINE
// ============================================================================
string pos = ui_position == "Top Right" ? position.top_right : 
             ui_position == "Bottom Left" ? position.bottom_left : 
             position.bottom_right

var table dash = table.new(pos, 3, 8, bgcolor=color.new(#131722, 15), frame_color=color.new(#2A2E39, 0), frame_width=1)

if barstate.islast
    // Header
    table.cell(dash, 0, 0, "PROCESS AUDIT", text_color=color.new(color.white, 30), text_size=size.small, text_halign=text.align_left, bgcolor=color.new(#2A2E39, 0))
    table.cell(dash, 1, 0, "VOL", text_color=color.new(color.white, 30), text_size=size.small, text_halign=text.align_right, bgcolor=color.new(#2A2E39, 0))
    table.cell(dash, 2, 0, "%", text_color=color.new(color.white, 30), text_size=size.small, text_halign=text.align_right, bgcolor=color.new(#2A2E39, 0))

    // Iterate through objects and render rows
    for i = 0 to array.size(gradeArray) - 1
        GradeMetrics g = array.get(gradeArray, i)
        table.cell(dash, 0, i+1, g.label, text_color=g.theme, text_size=size.small, text_halign=text.align_left)
        table.cell(dash, 1, i+1, str.tostring(g.count), text_color=color.white, text_size=size.small, text_halign=text.align_right)
        table.cell(dash, 2, i+1, str.tostring(g.weight, "#.1") + "%", text_color=color.white, text_size=size.small, text_halign=text.align_right)

    // Footer / Weighted Index
    table.cell(dash, 0, 7, "DISCIPLINE INDEX", text_color=color.white, text_size=size.small, text_halign=text.align_left, bgcolor=color.new(#2A2E39, 0))
    table.cell(dash, 1, 7, str.tostring(disciplineIndex, "#.1"), text_color=indexColor, text_size=size.normal, text_halign=text.align_right, bgcolor=color.new(#2A2E39, 0))
    table.merge_cells(dash, 1, 7, 2, 7)

Posted: **Mon Sep 21, 2026 10:07 pm**

Why this architecture fits a systematic workflow:

Object-Oriented Structure: By defining GradeMetrics as a custom type, the code isolates state from UI rendering. If you want to port this logic later to cAlgo or adapt it into a REST API payload for a custom journal database, the data structure is already decoupled.

The Discipline Index: Tracking raw A's and F's is helpful, but the Weighted Index distills your entire session into a single quantifiable metric (0-100 scale). It removes the guesswork from answering, "Was I disciplined today?"

Scalability: Because it relies on an array iteration loop rather than hardcoded rows for the rendering engine, adding new metrics (e.g., tracking partial exits or missed entries) simply requires instantiating a new object and pushing it to the array.

Posted: **Mon Sep 21, 2026 10:09 pm**

This implementation uses a single, cross-compatible codebase that compiles natively in both MetaEditor 4 (MQL4) and MetaEditor 5 (MQL5).

The GUI is constructed using native OBJ_LABEL and OBJ_RECTANGLE_LABEL objects. By relying on a universal coordinate inversion matrix, the dashboard can anchor to any corner dynamically without obscuring the raw price action and candlestick structures on your charts.

Posted: **Mon Sep 21, 2026 10:09 pm**

Code: Select all

//+------------------------------------------------------------------+
//|                                     Execution Grading Matrix.mq5 |
//+------------------------------------------------------------------+
#property strict
#property indicator_chart_window
#property indicator_plots 0

// ============================================================================
// INPUT PARAMETERS (Session / Weekly Log)
// ============================================================================
input string   G_LOG_      = "--- Execution Grading Log ---";
input int      InpGradeA   = 0; // Grade A (Perfect Process)
input int      InpGradeB   = 0; // Grade B (Minor Infraction)
input int      InpGradeC   = 0; // Grade C (Marginal)
input int      InpGradeD   = 0; // Grade D (Poor)
input int      InpGradeF   = 0; // Grade F (Total Failure)

enum ENUM_DASH_POS 
  {
   POS_TOP_LEFT,
   POS_TOP_RIGHT,
   POS_BOTTOM_LEFT,
   POS_BOTTOM_RIGHT
  };
input string   G_UI_       = "--- UI / UX Settings ---";
input ENUM_DASH_POS InpPosition = POS_BOTTOM_RIGHT; // Dashboard Position

// ============================================================================
// GLOBAL VARIABLES & UI CONFIGURATION
// ============================================================================
string prefix = "WDI_Dash_";

int marginX   = 20;
int marginY   = 20;
int boxWidth  = 230;
int boxHeight = 175;

// Theme Colors
color colBg       = clrBlack;
color colHeader   = clrSilver;
color colWhite    = clrWhite;
color colA        = clrLimeGreen;
color colB        = clrMediumSpringGreen;
color colC        = clrGold;
color colD        = clrDarkOrange;
color colF        = clrRed;

//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int OnInit()
  {
   DrawDashboard();
   return(INIT_SUCCEEDED);
  }

//+------------------------------------------------------------------+
//| Custom indicator deinitialization function                       |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
   ObjectsDeleteAll(0, prefix);
   ChartRedraw(0);
  }

//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   return(rates_total);
  }

// ============================================================================
// RENDERING ENGINE
// ============================================================================
void DrawDashboard()
  {
   ObjectsDeleteAll(0, prefix);
   
   int totalTrades = InpGradeA + InpGradeB + InpGradeC + InpGradeD + InpGradeF;
   double totalScore = (InpGradeA * 4.0) + (InpGradeB * 3.0) + (InpGradeC * 2.0) + (InpGradeD * 1.0) + (InpGradeF * 0.0);
   double maxScore = totalTrades * 4.0;
   double wdi = (totalTrades > 0) ? (totalScore / maxScore) * 100.0 : 0.0;
   
   color indexColor = (wdi >= 85.0) ? colA : ((wdi >= 70.0) ? colC : colF);
   
   // Base Container
   CreateBackground("Bg", 0, 0, boxWidth, boxHeight);
   
   // Table Headers
   int y = 15;
   AddLabel("H1", "PROCESS AUDIT", 15, y, colHeader, 0, true);
   AddLabel("H2", "VOL", 160, y, colHeader, 1, true);
   AddLabel("H3", "%", 215, y, colHeader, 1, true);
   
   // Data Rows
   y += 22; AddRow("R_A", "A (Perfect)", InpGradeA, totalTrades, colA, y);
   y += 20; AddRow("R_B", "B (Acceptable)", InpGradeB, totalTrades, colB, y);
   y += 20; AddRow("R_C", "C (Marginal)", InpGradeC, totalTrades, colC, y);
   y += 20; AddRow("R_D", "D (Poor)", InpGradeD, totalTrades, colD, y);
   y += 20; AddRow("R_F", "F (Failure)", InpGradeF, totalTrades, colF, y);
   
   // Footer Index
   y += 30;
   AddLabel("F1", "DISCIPLINE INDEX", 15, y, colWhite, 0, false);
   AddLabel("F2", DoubleToString(wdi, 1), 215, y - 2, indexColor, 1, true, 11);
   
   ChartRedraw(0);
  }

// ============================================================================
// COMPONENT HELPERS
// ============================================================================
void AddRow(string id, string label, int count, int total, color clr, int y)
  {
   AddLabel(id+"_L", label, 15, y, clr, 0, false);
   AddLabel(id+"_V", IntegerToString(count), 160, y, colWhite, 1, false);
   
   double pct = (total > 0) ? ((double)count / total) * 100.0 : 0.0;
   AddLabel(id+"_P", DoubleToString(pct, 1)+"%", 215, y, colWhite, 1, false);
  }

void CreateBackground(string name, int offsetX, int offsetY, int width, int height)
  {
   string objName = prefix + name;
   ObjectCreate(0, objName, OBJ_RECTANGLE_LABEL, 0, 0, 0);
   
   int corner = (int)InpPosition;
   ObjectSetInteger(0, objName, OBJPROP_CORNER, corner);
   ObjectSetInteger(0, objName, OBJPROP_ANCHOR, ANCHOR_LEFT_UPPER);
   
   int x = (corner == 1 || corner == 3) ? marginX + boxWidth - offsetX : marginX + offsetX;
   int y = (corner == 2 || corner == 3) ? marginY + boxHeight - offsetY : marginY + offsetY;
   
   ObjectSetInteger(0, objName, OBJPROP_XDISTANCE, x);
   ObjectSetInteger(0, objName, OBJPROP_YDISTANCE, y);
   ObjectSetInteger(0, objName, OBJPROP_XSIZE, width);
   ObjectSetInteger(0, objName, OBJPROP_YSIZE, height);
   ObjectSetInteger(0, objName, OBJPROP_BGCOLOR, colBg);
   ObjectSetInteger(0, objName, OBJPROP_BORDER_TYPE, BORDER_FLAT);
   ObjectSetInteger(0, objName, OBJPROP_COLOR, clrDarkGray);
   ObjectSetInteger(0, objName, OBJPROP_SELECTABLE, false);
   ObjectSetInteger(0, objName, OBJPROP_HIDDEN, true);
  }

void AddLabel(string name, string text, int offsetX, int offsetY, color clr, int align, bool isHeader, int overrideSize=0)
  {
   string objName = prefix + name;
   ObjectCreate(0, objName, OBJ_LABEL, 0, 0, 0);
   
   int corner = (int)InpPosition;
   ObjectSetInteger(0, objName, OBJPROP_CORNER, corner);
   
   int x = (corner == 1 || corner == 3) ? marginX + boxWidth - offsetX : marginX + offsetX;
   int y = (corner == 2 || corner == 3) ? marginY + boxHeight - offsetY : marginY + offsetY;
   
   ObjectSetInteger(0, objName, OBJPROP_XDISTANCE, x);
   ObjectSetInteger(0, objName, OBJPROP_YDISTANCE, y);
   
   ObjectSetString(0, objName, OBJPROP_TEXT, text);
   ObjectSetString(0, objName, OBJPROP_FONT, "Trebuchet MS");
   
   int fontSize = overrideSize > 0 ? overrideSize : (isHeader ? 8 : 9);
   ObjectSetInteger(0, objName, OBJPROP_FONTSIZE, fontSize);
   ObjectSetInteger(0, objName, OBJPROP_COLOR, clr);
   
   ENUM_ANCHOR_POINT anchor = (align == 0) ? ANCHOR_LEFT_UPPER : ANCHOR_RIGHT_UPPER;
   ObjectSetInteger(0, objName, OBJPROP_ANCHOR, anchor);
   
   ObjectSetInteger(0, objName, OBJPROP_BACK, false);
   ObjectSetInteger(0, objName, OBJPROP_SELECTABLE, false);
   ObjectSetInteger(0, objName, OBJPROP_HIDDEN, true);
  }
//+------------------------------------------------------------------+

forex-scalping.com

Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management

Re: Exponencial money management