Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Le sessioni di trading e di quotazione non aiutano a risolvere il problema?
Purtroppo no. Secondo le specifiche del contratto, la sessione di quotazione inizia alle 00:00:00 di lunedì.
In realtà, qui Rosh dà la risposta che l'inizio di una sessione di quotazioni non garantisce la disponibilità di quotazioni in essa. Il che è, in linea di principio, comprensibile.
Finora sto usando una "stampella" sotto forma del seguente controllo:
Sarei grato se qualcuno potesse condividere una soluzione più elegante (tutti gli utenti multivaluta devono aver incontrato questo problema).
P.S.
Konstantin Gruzdev offre una variante elegante nel suo articolo Implementing the multicurrency mode in MetaTrader 5.
Ma questa variante non soddisfa i requisiti per il campionato.
Accidenti... che ha colpito un nervo scoperto. :)) L'ultima riga è stata corretta a mano in un post del forum, quindi perdonatemi. =)
A proposito, anche il tuo codice non ha compilato (ho dimenticato di mettere una parentesi di chiusura nell'ultima riga). :-Р
Inoltre è 2-3 volte più lento (ora l'ho controllato su script), ma la qualità del controllo è la stessa. :-Р
Comunque, finché non c'è un codice adeguato per determinare il numero intero significativo, seguirò il consiglio di Composter: normalizzare il volume a 8 cifre decimali.
Speriamo che non ci siano insidie.
Riferimento:
Функцию Sleep() нельзя вызывать из пользовательских индикаторов, так как индикаторы выполняются в интерфейсном потоке и не должны его тормозить.
È davvero, davvero impossibile, o se lo si vuole davvero, si può, ma con attenzione? :)
Problema di accesso ai dati di un altro simbolo dall'indicatore.
se non ci sono zecche)
OrderCheck non aiuta?
No. Scrivo una riga prima dello scambio:
C'è ancora un errore nel registro. :(
E che dire della normalizzazione dei lotti?
Ragazzi, perché teorizzare?
Una situazione in cui l'incremento del lotto sarà maggiore del lotto minimo è assurda. Bene, immaginate: min = 0,1, passo = 1,0. Quindi, solo i lotti 1.1, 2.1, 3.1, ... sono ammessi? Questa è una sciocchezza.
Se stai esercitando l'aritmetica e la programmazione, allora le tue opzioni vinceranno. Ma se stiamo parlando di programmazione applicata (nel senso di trading), allora a lot_step > lot_min dobbiamo terminare il programma con un errore critico e cambiare urgentemente il broker, perché non ha abbastanza soldi nemmeno per lo stipendio di una persona che normalmente configurerebbe il server).
Tutto deve essere con moderazione. La mia variante ha lavorato sui reali per più di 5 anni, con diversi broker, tipi di conto, strumenti - mai avuto un errore.komposter
Perché è assurdo? Facciamo un semplice esempio: min_lot = 1.0, min_step = 0.3. I requisiti soddisfano il principio del "no nonsense" (min_lot >= lot_step). :)
Si passa 1,3 lotti di volume alla funzione di normalizzazione. Da esso si restituiscono 1,2 lotti.
La versione aggiornata restituirà 1.3. I suoi passi sono "corretti": dal lotto minimo, non da zero.
Un altro problema è la presenza di passi "nella vita" diversi da"1,0, 0,1, 0,01, ecc.
Qui, mi sembra, il costo del problema (perdita di prestazioni) è trascurabile rispetto alla soluzione di un possibile errore ipotetico. IMHO.
Dopo tutto, è semplicemente più corretto contare in questo modo: passi dal lotto minimo, non da zero.
No. Scrivo una riga prima di scambiare:
C'è ancora un errore nei log. :(
Guardate, sui conti del campionato tutti gli strumenti sono scambiati allo stesso tempo. Registro)
TradeCheckResult.retcode != TRADE_RETCODE_DONENon sono così sicuro di questa condizione...
Non so se questa condizione è corretta o no:
if(prezzo corrente == 0,0) ritorno;
komposter
Perché è assurdo? Facciamo un esempio semplice: lotto minimo = 1,0, passo minimo = 0,3. I requisiti soddisfano il principio del "no nonsense" (min_lot >= lot_step). :)
Si passa 1,3 lotti di volume alla funzione di normalizzazione. Da esso vengono restituiti 1,2 lotti.
La versione aggiornata restituirà 1.3. I suoi passi sono "corretti": dal lotto minimo, non da zero.
Un altro problema è la presenza di passi "nella vita" diversi da"1,0, 0,1, 0,01, ecc.
Qui, mi sembra, il costo del problema (perdita di prestazioni) è trascurabile rispetto alla soluzione di un possibile errore ipotetico. IMHO.
Dopo tutto, è semplicemente più corretto contare in questo modo: passi dal lotto minimo, non da zero.
"lotto minimo = 1,0, passo minimo = 0,3" è anche assurdo. I gradini dovrebbero essere un multiplo del lotto minimo.
Ho già espresso la mia opinione - in una gara di matematica e programmazione, la variante di sottrazione min_lot vincerà, non è necessaria per il trading reale.
Non vedo l'argomento per ulteriori discussioni, ognuno ha fatto la sua strada ;)