Storia di zecca - pagina 24
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
A giudicare dalle query dell'indicatore di tick, i dati del campo time_msk sono un multiplo di 1000. cioè non stiamo parlando di millisecondi, la risoluzione è 1 secondo.
Domanda: che senso aveva allora estendere la struttura di MqlTick?
Non è così da voi?
Ho una demo su Openbroker e un conto reale sullo stesso posto. Sul server reale all Access dà lo stesso risultato. beh sulla demo lo stesso. Guardato Si-6.16, RTS-6.16, SBRF-6.16. Tutti i cambiamenti sono multipli di 1000.
Non è così?
In questo momento, la query SymbolInfoTick restituisce degli zeri nella struttura MqlTick invece di millisecondi reali (un multiplo di 1000)
Si prega di attendere la prossima build.
PS su richiesta i millisecondi di CopyTicks sono dati così come sono
Ho scaricato questo indicatore da questo thread per testarlo. Ottiene esattamente gli ultimi 30 tick tramite CopyTicks. Come opzione, forse dovrei provare su un server diverso (non openbroker).
>>"gli zeri sono dati al posto dei millisecondi reali".
Non vengono dati zeri, ma sempre gli stessi numeri con un multiplo di 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Ho scaricato questo indicatore da questo thread per testarlo. Ottiene esattamente gli ultimi 30 tick tramite CopyTicks. Come opzione, forse dovrei provare su un server diverso (non openbroker).
>>"gli zeri sono dati al posto dei millisecondi reali".
Non vengono dati zeri, ma sempre gli stessi numeri con un multiplo di 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Gli zeri sono passati dalla funzione SymbolInfoTick.
In CopyTicks vengono dati millisecondi reali. Se questi sono 2064, 3064, 4064, significa che era così. Perché sia stato così, non lo so.
Ho dato un'occhiata al tuo codice. Qual è lo specificatore di output %-4d? time_msc è lungo, quindi solo d non funziona. Dovrebbe essere %I64d.
Gli zeri sono dati dalla funzione SymbolInfoTick.
In CopyTicks vengono dati millisecondi reali. Se è 2064, 3064, 4064, così è stato. Perché fosse così, non lo so.
Ho dato un'occhiata al tuo codice. Qual è lo specificatore di output %-4d? time_msc è lungo, quindi solo d non funziona. Dovrebbe essere %I64d.
Sì, scusate. Il codice non è mio. L'autore del codice ha davvero un lapsus in StringFormat. Ho stampato in ogni iterazione del ciclo attraverso Print (tick.time_msc) . Il risultato è tutti zeri alla fine e non otteniamo ancora nessun millisecondo. La richiesta diCopyTicks persiste.
Gli zeri sono dati dalla funzione SymbolInfoTick.
In CopyTicks vengono dati millisecondi reali. Se è 2064, 3064, 4064, così è stato. Perché sia stato così, non lo so.
Ho guardato il tuo codice. Qual è lo specificatore di output %-4d? time_msc - è lungo, ecco perché solo d non funziona. Dovrebbe essere %I64d.
Indicatore modificato dal primo post - non giocare con StringFormat, dovrebbe essere così ora:
Sì, scusate. Il codice non è mio. L'autore ha davvero un bug in StringFormat. Stampa (tick.time_msc) in ogni iterazione del ciclo. Il risultato è tutti zeri alla fine e non otteniamo ancora nessun millisecondo. La richiestaCopyTicks va sempre.
Ecco il tuo indicatore su dati MetaQuotes Demo
Chiedete al vostro broker l'assenza di millisecondi in tick
Ecco il tuo indicatore su dati MetaQuotes Demo
Chiedete al vostro broker della mancanza di millisecondi in tick
ps il mio cliente costruisce 1340
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
Ho anche una domanda, anche se con un piano leggermente diverso, e mi chiedo anche se le informazioni trasmesse dalle zecche siano corrette.
Una domanda sui volumi reali.
Se richiedi informazioni sui tick dall'indicatore, il volume reale va lì nell'array volume[]. E, in teoria, se ottieni informazioni dai tick, il volume accumulato per candela dovrebbe corrispondere al valore dell'array volume[].
Ecco un esempio di codice di prova:
Non attacchiamoci alle bandiere per ora e assumiamo che ogni tick ricevuto modifichi il volume totale di sVol (anche se, per quanto ne so, non è così).
Stiamo aspettando la formazione di una nuova candela e guardiamo le voci nel diario. Apertura broker, conto reale, build 1340, RTS-6.16:
E così via, il volume reale dell'indicatore sarà molto più grande di quello accumulato. Questo solleva alcune domande per gli sviluppatori:
1. Il volume ottenuto dall'array volume[] della funzione OnCalculate() deve essere uguale al volume accumulato ottenuto dai tick? La mia opinione, ovviamente, dovrebbe, altrimenti perché indicarla tra i segni di spunta?
2. È corretto utilizzare la funzione OnCalculate() per accumulare il volume o è meglio ottenere il volume tramite OnBookEvent()? L'aiuto dice:
L' evento Calculate viene generato solo per gli indicatori immediatamente dopo l'invio dell'evento Init e ad ogni variazione dei dati di prezzo. Gestito dalla funzione OnCalculate.
quindi, in teoria, è corretto, ma vorrei sentire un commento in merito.
3. I risultati del test vengono mostrati SENZA analisi flag. Se analizziamo i flag, quindi, per quanto ho capito, devi prendere i volumi dai tick con i flag 24 (modifica simultanea dell'ultimo e del volume):
Ma in questo caso, il volume accumulato sarà ancora inferiore. Vorrei sentire i commenti degli sviluppatori su come analizzare correttamente i tick ora (poiché tutti i campi sono registrati) e i flag sono implementati correttamente? La domanda sulla correttezza dell'implementazione è sorta perché non ho notato segni di spunta con i flag:
Il file indicatore è anche nell'applicazione.