Continuando il tema del lancio delle librerie MQL5 sotto MT4
#property strict // https://www.mql5.com/ru/docs/standardlibrary/graphics/cgraphic #include <Graphics\Graphic.mqh> // MQL5\Include\Graphics\Graphic.mqh void OnStart() { double Y[] = {1, 2}; GraphPlot(Y); }
Spesso nel tester, se il cursore della velocità è impostato su 31, è lento, se è impostato su 32, il test si precipita alla sua conclusione con la supervelocità.
Ne esco inserendo nel codice un ritardo attraverso il contatore:
input int gDelay = 10000; // Счетчик для задержки, off=0 void OnTick() { int delayCount = 0; while(delayCount < gDelay) ++delayCount; }
Il ritardo tramite l'ingresso può essere regolato a seconda della velocità dell'EA e della potenza del processore.
A velocità 32 posso ora spostarmi verso i punti di interesse alla velocità che mi conviene.
Di seguito tratteremo un argomento che non riguarda solo MT4, ma anche MT5 con altre piattaforme. Ma la logica sarà scritta in MQL4 per una facile percezione, quindi in questo ramo.
Il più delle volte la spina dorsale (la carne di qualsiasi ordine) della modifica/cancellazione dell'ordine si riduce alla seguente logica
// Самый распространенный костяк логики модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration());
Ora, l'approccio è raro, ma molto più corretto
// Редкий, но правильный костяк модификации ордеров for (int i = OrdersTotal() - 1; i >= 0; i--) if (OrderSelect(i, SELECT_BY_POS)) if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration())) { i = OrdersTotal(); // Хотя бы так // А лучше так // OnTick(); break; // вместо строки выше лучше делать такой вызов (переполнения стека от рекурсивных вызовов быть не должно) }
Dopo aver inviato un ordine di compravendita, l'ambiente di compravendita cambia, quindi è consigliabile eseguire l'intera logica di compravendita del TS da zero immediatamente dopo la risposta del server di compravendita.
Ora l'approccio è raro, ma molto più corretto
Questa variante si aggancia alla modifica dell'ultimo ordine nella lista a qualsiasi errore, e l'Expert Advisor che ha più di 1 ordine "perde di vista" tutti gli altri.
La mia ricetta: fare un loop di tutti i suoi ordini, processare ognuno di essi (aggiornando le informazioni di mercato prima di processarli, se necessario), e al prossimo tick, il prossimo approccio. In alcuni casi, l'approccio successivo (chiamata OnTick) può essere fatto immediatamente dopo che il ciclo corrente è finito, se ci sono stati errori in esso.
Questa opzione fa un loop sulla modifica dell'ultimo ordine nella lista quando c'è qualche errore, e un EA con più di 1 ordine "perde di vista" tutti gli altri.
Non ci sarà nessun looping a causa di questa condizione
if (OrderModify(OrderTicket(), Price, SL, TP, OrderExpiration()))
La mia prescrizione: fai un loop di tutti i tuoi ordini, processa ognuno di essi (aggiornando le informazioni di mercato prima di processarli, se necessario) e al prossimo tick, il prossimo approccio. In alcuni casi, il prossimo approccio (chiamata OnTick) può essere fatto subito dopo la fine del ciclo corrente se ci sono stati errori in esso.
Poi altri errori di richieste commerciali possono essere visti nel log del terminale.
Non ci sarà nessun looping a causa di questa condizione
Sì, sbagliato, leggilo come !OrderModify.
Se la modifica ha successo, l'elaborazione non può nemmeno essere ripetuta dall'inizio della lista, perché in questo caso un ordine sarà anche modificato (per esempio tirato su dietro il prezzo) e gli altri potrebbero essere lasciati incustoditi per molto tempo.
La mia ricetta è ancora valida.
Questo non l'ho capito.
Se la modifica ha successo, l'elaborazione non può nemmeno essere ripetuta dall'inizio della lista, perché in questo caso un ordine sarà anche modificato (per esempio tirando su dietro il prezzo), e gli altri potrebbero essere lasciati incustoditi per molto tempo.
C'è qualcosa di sbagliato in questa logica fin dall'inizio. Dobbiamo fare una scelta consapevole: è meglio avere un ordine effettivo o molti ordini irrilevanti.
La mia prescrizione è ancora valida.
Questo non l'ho capito.
Lasciate che OrderModify venga eseguito per 5 secondi. Durante la sua esecuzione, lasciamo che un ordine limite parziale sia eseguito più volte sul server di trading, generando una dozzina di trade.
Qualcosa in questa logica è sbagliato fin dall'inizio. Bisogna fare una scelta consapevole: meglio un ordine effettivo o molti ordini irrilevanti.
Un ordine non può essere a diversi livelli allo stesso tempo. O dovremmo avere un EA diverso per ogni livello? Questa è una soluzione discutibile per la grande maggioranza delle strategie.
Come caso speciale, diverse posizioni (guadagnate per tendenza con diverse entrate) e un trailing stop per loro. Tirare lo SL di un solo trade o modificarli tutti? Su un brusco movimento con lo stesso brusco rollback successivo, l'opzione di modificare solo un ordine perderà molto (e non arriveremo al resto, perché ogni nuova chiamata a OnTick modificherà il primissimo ordine della lista).
Lasciate che OrderModify venga eseguito per 5 secondi. Durante la sua esecuzione, supponiamo che un ordine limite parziale sia stato eseguito diverse volte sul server di trading, avendo generato una dozzina di operazioni.
Supponiamo che. Elaboreremo tutti gli ordini che sono stati (e dovrebbero essere) eseguiti, e passeremo ai nuovi sul prossimo tick o direttamente dopo il primo ciclo.
Altrimenti rischiamo sempre di lavorare con una - ultima - parte eseguita di un ultimo ordine. Forse la parte più piccola. Lasciando un grosso ordine appeso lì incustodito.
Un ordine non può essere a diversi livelli allo stesso tempo. O dovremmo avere un EA diverso per ogni livello? Questa è una soluzione discutibile per la grande maggioranza delle strategie.
Come caso speciale, diverse posizioni (guadagnate per tendenza con diverse entrate) e un trailing stop per loro. Tirare lo SL di un solo trade o modificarli tutti? Se abbiamo un forte movimento con un altrettanto forte pullback successivo, l'opzione di modificare solo un ordine perderebbe molto (e non raggiungeremo il resto, perché ogni nuova chiamata a OnTick modificherà il primo ordine della lista).
Non capisco perché OnTick dovrebbe modificare solo un ordine? Tutti saranno modificati.
Diciamo. Elaboreremo tutti gli ordini che sono stati (e dovrebbero essere) elaborati e passeremo a quelli nuovi al prossimo tick o immediatamente dopo il primo ciclo.
Altrimenti rischieremo sempre di lavorare con una - l'ultima - parte eseguita di un ultimo ordine. Forse la parte più piccola. Lasciando un grosso ordine appeso lì incustodito.
Richiamo l'attenzione sulla parola "spina dorsale". La carne sotto forma di selezione della priorità del lotto o di qualcos'altro può sempre essere costruita. La logica di base, d'altra parte, rimane la stessa: dopo un ordine di trading andato a buon fine, si esegue l'intera logica di trading da zero.
Non capisco perché OnTick modificherà solo un ordine? Tutto sarà modificato.
Perché il prezzo si muoverà, e ad ogni nuova chiamata a OnTick, la condizione per una nuova modifica dello stesso ordine, il primo della lista, sarà soddisfatta. Soprattutto se la modifica durerà 5 secondi ;)
Notate la parola "spina dorsale". La carne sotto forma di selezione prioritaria del lotto o qualcos'altro può sempre essere aggiunta. La logica di base, d'altra parte, rimane la stessa: dopo un ordine di compravendita riuscito, esegue tutta la logica di compravendita da zero.
Una tale "spina dorsale" romperebbe la logica di un EA che lavora con più di un ordine.
Che senso ha se non darà alcun vantaggio ai sistemi con un ordine e rovinerà gli altri?
Ordinare per volume e/o distanza dal prezzo prima di lavorare con gli ordini è una buona soluzione. Ma non dobbiamo dare per scontato che tutti quelli che copiano il codice dal forum lo implementino.
In questo senso, il mio codice è più sicuro.
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso