L'errore è stato effettivamente riprodotto, ma non immediatamente. A quanto pare, non hanno aggiustato tutto - bisogna continuare a riprodurre, ma non si riproduce.
joo: Ho fatto un rapido aggiornamento alla 567 e non ho notato alcun problema. Il volo va bene. :)
Sembra essere ok anche, voglio solo essere sicuro che sia una build nativa e non un trovatello. ))) Se nativo, perché non è stato annunciato? Qualcuno ha già scritto che dopo l'ultimo aggiornamento l'autodistruzione delle cartelle nel terminale di directory, quindi mi sono preoccupato un po'. Hai tutto pronto finora? )))
Per la lista dei timeframe, per ottenere i loro nomi, c'è EnumToString() - restituisce il nome del timeframe come una stringa. È possibile ottenere come stringa i nomi delle costanti di visibilità degli oggetti incorporati di tipo OBJ_PERIOD_M5?
x100intraday: Per la lista dei timeframe, per ottenere i loro nomi, c'è EnumToString() - restituisce il nome del timeframe come una stringa. È possibile ottenere come stringa i nomi delle costanti di visibilità degli oggetti incorporati di tipo OBJ_PERIOD_M5?
No, in realtà questa è una macro (#define), tale funzionalità non è prevista per le macro.
mql5: No, questa è in realtà una macro (#define), nessuna funzionalità del genere è prevista per le macro.
C'è qualche relazione tra la struttura della lista di timeframes e i flag di visibilità degli oggetti (perché anche la lunghezza delle liste è diversa: 22 vs 23)? In generale, lo chiedo per assegnare in modo efficiente e compatto la visibilità degli oggetti sui tempi di un ciclo con dei confini dati, piuttosto che elencare e riassumere manualmente le bandiere. Quale logica usare se un timeframe arbitrario è preso a caso, un oggetto grafico è costruito su di esso e deve essere permesso di essere visibile su tutti i timeframe non più vecchi di quello corrente (cioè quello su cui è stato costruito)? L'algoritmo dovrebbe essere universale, non per un caso particolare. La correlazione dell'indice è già fregata, non c'è nemmeno una corrispondenza dell'indice. L'analisi delle stringhe di nomi e il confronto è di nuovo un fallimento a causa dell'impossibilità di gestire le stringhe in caso di costanti di visibilità. Finora, mi viene in mente un'implementazione complicata, vaga e molto storta.
Ho inviato i registri l'altro ieri. Vi farò sapere... in qualche modo mi è sfuggito... perché hai scritto che hai riprodotto l'errore.
I registri sono arrivati, grazie. Li abbiamo guardati. E la domanda non riguardava i registri, ma il file.
Hanno riprodotto l'errore, ma non immediatamente. A quanto pare non hanno sistemato tutto - bisogna riprodurlo ulteriormente, ma non si riproduce.
La domanda non riguarda i registri, ma il file.
L'errore è stato effettivamente riprodotto, ma non immediatamente. A quanto pare, non hanno aggiustato tutto - bisogna continuare a riprodurre, ma non si riproduce.
ha risposto
Ho fatto un rapido aggiornamento alla 567 e non ho notato alcun problema. Il volo va bene. :)
tol64:
Hai già messo tutto a posto? )))
Fin qui tutto bene, voglio solo assicurarmi che sia una build nativa e non un trovatello. )))
joo: Всё на месте.
alexvd: Non preoccuparti, la build è nativa. Potete controllare le firme dei file.Per la lista dei timeframe, per ottenere i loro nomi, c'è EnumToString() - restituisce il nome del timeframe come una stringa. È possibile ottenere come stringa i nomi delle costanti di visibilità degli oggetti incorporati di tipo OBJ_PERIOD_M5?
No, questa è in realtà una macro (#define), nessuna funzionalità del genere è prevista per le macro.
C'è qualche relazione tra la struttura della lista di timeframes e i flag di visibilità degli oggetti (perché anche la lunghezza delle liste è diversa: 22 vs 23)? In generale, lo chiedo per assegnare in modo efficiente e compatto la visibilità degli oggetti sui tempi di un ciclo con dei confini dati, piuttosto che elencare e riassumere manualmente le bandiere. Quale logica usare se un timeframe arbitrario è preso a caso, un oggetto grafico è costruito su di esso e deve essere permesso di essere visibile su tutti i timeframe non più vecchi di quello corrente (cioè quello su cui è stato costruito)? L'algoritmo dovrebbe essere universale, non per un caso particolare. La correlazione dell'indice è già fregata, non c'è nemmeno una corrispondenza dell'indice. L'analisi delle stringhe di nomi e il confronto è di nuovo un fallimento a causa dell'impossibilità di gestire le stringhe in caso di costanti di visibilità. Finora, mi viene in mente un'implementazione complicata, vaga e molto storta.