Servicedesk: pigrizia, autismo o mancanza di volontà di ammettere gli errori? Completare i grafici con candele non native.
È questa la domanda che hai sollevato un mese fa? https://www.mql5.com/ru/forum/1111/page878#comment_344461
CinquantaStelle:
...La storia è quella che è. Non abbiamo una storia minuziosa. Per comodità, la storia più profonda è rappresentata da barre giornaliere.
Se non è conveniente per voi, limitate l'uso di questa cronologia manualmente.
Il succo della risposta era già noto all'epoca(https://www.mql5.com/ru/forum/1111/page878#comment_344518):
Ma ho paura che (la risposta) sarà qualcosa del genere: "Il programmatore stesso può calcolare la data limite e limitare la profondità della storia richiesta.
Ho contattato il Service Desk per un problema con l'aggiunta di candele più alte ai grafici a basso TF quando non c'è storia sui TF inferiori. Cioè quando andiamo all'inizio della storia nel grafico M1, vediamo le candele non da M1, ma da D1, o anche da W1. A causa di questa adesione, la funzione SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) restituisce non la data in cui termina la storia M1, ma la data della prima barra al di fuori del timeframe, cioè il timeframe specificato non influenza il risultato.
...
SERIES_BARS_COUNT restituisce il numero di candele (barre) appartenenti a un certo simbolo e timeframe
SERIES_FIRSTDATE restituisce la data della prima candela (barra) aperta, che appartiene ad un certo simbolo e timeframe.
Più informazioni
...
Le funzioni funzionano correttamente.
Quello che vedi è una conseguenza della tua precedente richiesta di qualità della storia.
La storia è quella che è. Non abbiamo una storia minuta e profonda. Per comodità, la storia più profonda è rappresentata da barre giornaliere.
Se non è conveniente per voi, limitate l'uso di questa cronologia manualmente.
Questa è una scusa franca, il programmatore non può prevedere tutte le varianti della storia che morde, quindi non può prescrivere la funzione di ricerca della prima data del TF. Oggi sono così, e domani avranno nuovi colpi di scena, e all'insaputa di MQ, per esempio spacciando rovinerà qualcosa.
E perché ne abbiamo bisogno quando c'è una funzione standard, ma il fatto che dia il tempo dell'altro ieri è già un vero e proprio bug.
Ecco il nocciolo del problema per il programmatore:
Dobbiamo cercare le varianti dei criteri secondo i quali questa barra può essere considerata la prima barra del TF selezionato, e tutte quelle precedenti - l'aggiunta dal TF più vecchio. Ci possono essere dei vuoti nelle barre come una barra mancata (questa è una diretta conseguenza del formato di registrazione delle barre scelto da MQ) o dei vuoti nelle barre come un fine settimana/festivo. E in una tale cacofonia di segni non è chiaro come determinare che questo bar è quello giusto.
Qual è l'essenza del problema per MQ: (se intendiamo che lo risolveranno)
Quando la storia di cross-linking cripta in un file i dati sui punti di convergenza (non sono molti, un massimo di 21 dal numero di TF, in pratica, ci sono 2-3), il problema è risolto. Poi, scrivete una funzione per leggere queste informazioni protette e mostrarle all'utente tramite richiesta.
Grazie, non decidere per i commercianti.
Che testa fresca è stata quella di fare una tale mossa dopo venerdì - per inserire le barre più vecchie nel timeframeM1 ?
Chi vi ha dato il diritto di invertire molti anni di principi consolidati?
Se non vi sentite a vostro agio, limitate l'uso di questa storia manualmente.
Grazie, non decidere per i commercianti.
Che testa fresca è stata quella di fare una tale mossa dopo venerdì - per inserire barre senior nel timeframeM1 ?
Chi vi ha dato il diritto di rovesciare molti anni di principi stabiliti?
Alex, non esagerare, l'incollaggio dei TF era necessario per calcolare correttamente tutti gli altri TF, dopo che hanno deciso di calcolare tutti i TF da M1.
Se vi ricordate, ci permetteva di calcolare fino a 21 TF (compresi quelli non standard).
Non è stato detto più di una volta. Non torneremo al vecchio sistema di immagazzinare ogni TF separatamente, capite.
Ma il fatto che l'implementazione aggiunga più problemi per i programmatori è un fatto. E la domanda è semplice da risolvere, ma no, sappiamo meglio di cosa hai bisogno :(
quindi è questo che mi chiedo.
Если вам это не удобно - ограничивайте использование этой истории вручную.
Alex non esagerare, l'incollaggio dei TF era necessario per calcolare correttamente tutti gli altri TF, dopo la decisione di calcolare tutti i TF da M1.
Si risolve impostando l'identificatore nella cronologia e quando si legge se i dati della barra non appartengono a M1, allora non si emette su M1, non appartengono a M5, allora non si emette su M5. Oppure sì... dovremmo scrivere la data di unione delle barre del periodo corrente con quelle del periodo superiore in FirstDate e l'utente avrà la possibilità reale di sapere da quale data iniziare l'elaborazione per non prendere le barre più vecchie.
La situazione è certamente idiota.
Non è possibile disegnare tali grafici, né restituire tali valori dalle funzioni.
Se vuoi costruire da M1, costruiscilo. Non abbastanza M1 - capire come uscirne, ma non a nostre spese.
(tutti indirizzati, ovviamente, a MQ)
- www.mql5.com
Sono d'accordo, è spazzatura.
E se ci sono separatori di punti, è una bellezza.
E dovete attorcigliarlo nel codice ((.
- 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
Ho contattato il Service Desk per un problema con l'aggiunta di candele più alte ai grafici a basso TF quando non c'è storia sui TF inferiori. Significa che quando andiamo all'inizio della storia nel grafico M1, vediamo le candele non da M1, ma da D1, o anche da W1. A causa di questa adesione, la funzione SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x) restituisce non la data in cui termina la storia M1, ma la data della prima barra al di fuori del timeframe, cioè il timeframe specificato non influenza il risultato. Quando mi è stato chiesto, ho ricevuto una scusa che è conveniente per gli utenti e la data limite per ogni timeframe di ogni simbolo dovrebbe essere impostata manualmente. Scusate, ma questa funzione non dovrebbe essere eseguita dalla funzione SeriesInfoInteger(Symbol(), PERIOD_M1,SERIES_FIRSTDATE,x), e in che modoSERIES_FIRSTDATE differiscedaSERIES_FIRSTDATEnel TF M1 specificatose il risultato è lo stesso?
Cos'è questa sciocchezza? Chi e perché è conveniente? Nessuno vuole vedere candele W1 su grafici M1. Beh, tranne che per i masochisti...
Arrivo alla seguente conclusione: o gli sviluppatori sono autistici (vivono nel loro mondo, dove il sopra e il sotto sono la norma, o meglio non la norma, ma il lavoro è 5+), o sono troppo pigri per aggiustarlo, o il principio del "Come mai non sbagliamo mai, siamo tutti buoni". Beh, ci sono anche delle varianti: scherzano, non sanno come risolvere il problema.
Qui ci sono gli screenshot, si può vedere chiaramente la linea di unione della storia dei diversi TF:
https://charts.mql5.com/1/26/eurusd-d1-metaquotes-software-corp-7.png
https://charts.mql5.com/1/26/eurusd-h4-metaquotes-software-corp.png
https://charts.mql5.com/1/26/eurusd-h1-metaquotes-software-corp-9.png
https://charts.mql5.com/1/26/eurusd-m30-metaquotes-software-corp-2.png
https://charts.mql5.com/1/26/eurusd-m15-metaquotes-software-corp-6.png
domanda 1:
Versione e bit rate del terminale
Costruire 712 x86
Descrizione del problema.
I dati storici di piccoli timeframes sono continuati dai dati storici di timeframes più grandi. Significa, per esempio, che la storia di EURUSD su M1 termina il ~04.01.1999, e alla sua sinistra, attaccato al grafico M1 c'è il grafico D1 per il periodo fino al 04.01.1999.
Potete vederlo negli screenshot allegati. A causa di questo, la funzione SeriesInfoInteger con il parametro SERIES_FIRSTDATE funziona in modo errato. La funzione restituisce la prima data dell'intera storia (compresi i timeframe D1, W1 e MN1) invece della prima data del periodo simbolo.
La sequenza di azioni
Scorrere il grafico fino all'inizio della storia
Il risultato ottenuto
Continuazione del grafico con dati storici da timeframe più grandi.
Risultato atteso
Restrizione del grafico alla fine dei dati storici sul timeframe dato.
Informazioni aggiuntive
Richiesta 2:
Versione del terminale e bit rate
costruire 712 x86
Descrizione del problema
Descrizione nella documentazione:
NUMERO DI BARRE DELLA SERIE.
Numero di barre per periodo-simbolo al momento
lungo
DATA_PRIMA_SERIE
La prima data per il periodo di simbolo corrente
datetime
A causa dell'adesione della storia per il TF inferiore, nel caso dell'assenza di storia per un determinato periodo di tempo sul TF inferiore, e la presenza di storia per lo stesso periodo sul TF maggiore, il grafico, per esempio, M1 mostra candele dal grafico di D1.
Si sta preparando una soluzione a questo problema? C'è qualche soluzione di questo problema al momento, oltre alla limitazione manuale?
Sequenza di azioni
Utilizzando queste funzioni
Il risultato ottenuto
SERIES_BARS_COUNT su timeframe bassi (fino a D1) restituisce il numero di candele (barre), appartenenti al simbolo e al timeframe, più il numero di candele del timeframe più grande più vicino, per il quale sono disponibili i dati storici
SERIES_FIRSTDATE sui timeframe bassi (fino a D1) restituisce la data di apertura della prima candela (barra) nella storia.
Il risultato atteso
SERIES_BARS_COUNT restituisce il numero di candele (barre) appartenenti a un particolare simbolo e timeframe
SERIES_FIRSTDATE restituisce la data della prima candela (barra) aperta, che appartiene a un simbolo e a un timeframe specificato.
Più informazioni
...
Le funzioni funzionano correttamente.
Quello che vedi è una conseguenza della tua precedente richiesta di qualità della storia.
La storia è quella che è. Non abbiamo una storia minuta e profonda. Per comodità, la storia più profonda è rappresentata da barre giornaliere.
Se non è conveniente per voi, limitate l'uso di questa cronologia manualmente.