Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Vladimir, el problema no se produce en el probador... ¿Cómo es que hay tanto problema? ¿O porque sólo hay un Asesor Experto en el probador?
También sugerí en la SD que el único cambio era poner el segundo EA en un par diferente...
En un terminal (en el marco temporal M15 había EAs) no funcionaba en un símbolo - estoy 99% seguro de que el problema es que cuando se usa el marco temporal de otro se necesita "tirar" del historial todo el tiempo. Creo que es mejor hacerlo mediante CopyTime().
Esto no es un error. Estás trabajando en el tiempo de otra persona. En tal caso, usted mismo debe ocuparse de los datos de la agenda de otra persona para asegurarse de que están actualizados.
Personalmente, no veo ninguna alternativa.
No es un hecho que no sepamos cómo funcionaSERIES_LASTBAR_DATE. Puede ser que no haya necesidad de actualizar nada porque el tiempo de la última barra puede ser calculado usando TimeCurrent() del símbolo especificado. Hay que preguntar a los promotores.
Pero hasta ahora un hecho claro e indiscutible es que si dos variables dan verdadero, entonces juntas (al comprobar &&) estas variables también darán verdadero.
El problema de la caída de la caché de otras herramientas/TF existe.
Comprobar los errores y esperar en el bucle para cargar no siempre ayuda. Hemos estado hablando con el Servicio de Atención al Cliente, pero MQ no ha hecho ningún progreso, sólo una pista:
La sospecha es que los datos históricos se descargan por tiempo de espera.
Hay dos soluciones:
1. acceder a los datos con más frecuencia que una vez cada 3 minutos
2. Poner algún indicador muy simple en los datos. El volumen, por ejemplo. No hay cálculo, sólo un búfer está ocupado. La disponibilidad del indicador mantendrá la caché histórica en la memoria independientemente de la frecuencia de acceso
El segundo consejo no funciona, los indicadores son llamados todo el tiempo, pero en algún momento el caché falla y se hace imposible obtener datos.
Resolví el problema con esta muletilla - llamo a este código cada 150 segundos para todos los instrumentos/FTs involucrados:
Funciona bastante rápido, el error 4806 parece desaparecer después de esta actualización.
Por favor, comente otro malentendido.
Devuelve el número de barras en el historial por el símbolo del periodo correspondiente. Hay 2 variantes de la función.
Sólo la segunda opción es interesante.
Texto del Asesor Experto
Entiendo que la hora 00:00:00 pertenece al día, al igual que la hora 00:00:01
Pero... las impresiones propuestas no están de acuerdo con eso.
Resulta que entre el 2016.06.22 00:00:00 y el 2016.06.24 00:00:00 hay tres barras diarias y entre el 2016.06.22 00:01 y el 2016.06.24 00:00:00 sólo hay dos...
¿O estoy entendiendo mal algo?
Y si se añade un segundo al tiempo de la barra actual
se obtiene lo siguiente
La hora 2016.06.24 00:00:01 parece pertenecer al siguiente bar o ¿qué?
El límite de tiempo superior no se incluye en el intervalo en el que se determina el número de barras.
Dimitri, ¿no es extraño? Ha aparecido una nueva barra, pero no la contaremos todavía.
Escucha, ¿no es la razón de tal comportamiento de la SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE); ? Apareció una nueva barra, se ejecuta el código de la garrapata disponible, pero aún no se tiene en cuenta el tiempo...
Bueno, el baterista se ha desinflado... Y ha pasado completamente desapercibido...
Vladimir, ¿puedes al menos responder a esta pregunta?
¿CopiaRates() tira de la historia? ¿Hay tiempo en la estructura...?
Bueno, el hombre del saco se ha desinflado... Y ha sido totalmente ignorado...
Vladimir, ¿puedes al menos responder a esta pregunta?