Historia de la garrapata - página 24
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
A juzgar por las consultas del indicador de ticks, los datos del campo time_msk son un múltiplo de 1000. es decir, no estamos hablando de milisegundos, la resolución es de 1 segundo.
Pregunta: ¿qué sentido tenía entonces ampliar la estructura de MqlTick?
¿No es así en tu caso?
Tengo una demo en Openbroker y una cuenta real en el mismo sitio. En el servidor real all Access da el mismo resultado. bueno en la demo lo mismo. Se ha examinado Si-6.16, RTS-6.16, SBRF-6.16. Todos los cambios son múltiplos de 1000.
¿No es así?
Ahora mismo, la consulta SymbolInfoTick devuelve ceros en la estructura MqlTick en lugar de milisegundos reales (un múltiplo de 1000)
Por favor, espere a la siguiente compilación.
PS a petición CopyTicks milisegundos se dan como es
He descargado este indicador de este hilo para probarlo. Obtiene los últimos 30 ticks exactamente a través de CopyTicks. Otra posibilidad es que lo pruebe en otro servidor (no en openbroker).
>>"se dan ceros en lugar de milisegundos reales".
No se dan ceros, sino siempre los mismos números con un múltiplo de 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
He descargado este indicador de este hilo para probarlo. Obtiene los últimos 30 ticks exactamente a través de CopyTicks. Como opción, quizás debería probarlo en otro servidor (no en openbroker).
>>"se dan ceros en lugar de milisegundos reales".
No se dan ceros, sino siempre los mismos números con un múltiplo de 1000. (...2064, ...2064, ...3064, ..., ..., ..4064 )
Los ceros son pasados por la función SymbolInfoTick.
En CopyTicks se dan milisegundos reales. Si estos son 2064, 3064, 4064, significa que fue así. No sé por qué fue así.
He mirado su código. ¿Cuál es el especificador de salida %-4d? time_msc es largo, por lo que sólo d no funciona. Debería ser %I64d.
Los ceros vienen dados por la función SymbolInfoTick.
En CopyTicks se dan milisegundos reales. Si es 2064, 3064, 4064, así fue. No sé por qué fue así.
He mirado su código. ¿Cuál es el especificador de salida %-4d? time_msc es largo, por lo que sólo d no funciona. Debería ser %I64d.
Sí, lo siento. El código no es mío. El autor del código realmente tiene un desliz en StringFormat. Imprimí en cada iteración del bucle a través de Print (tick.time_msc) . El resultado es todo ceros al final y seguimos sin obtener milisegundos. La solicitud deCopyTicks persiste.
Los ceros vienen dados por la función SymbolInfoTick.
En CopyTicks se dan milisegundos reales. Si es 2064, 3064, 4064, así fue. No sé por qué fue así.
He mirado su código. ¿Qué es el especificador de salida %-4d? time_msc - es largo por eso solo d no funciona. Debería ser %I64d.
Indicador cambiado desde el primer post - no juegues con StringFormat, ahora debería ser así:
Sí, lo siento. El código no es mío. El autor realmente tiene un error en StringFormat. Imprimir (tick.time_msc) en cada iteración del bucle. El resultado es todo ceros al final y seguimos sin obtener milisegundos. La solicitudCopyTicks va todo el tiempo.
Aquí está su indicador en los datos de MetaQuotes Demo
Pregunte a su corredor sobre la ausencia de milisegundos en los ticks
Aquí está su indicador en los datos de MetaQuotes Demo
Pregunte a su corredor sobre la falta de milisegundos en los ticks
ps mi cliente construye 1340
juriy5555 :
Пока не знаю, что и у кому конкретно писать, я в этом несколько месяцев. Буду надеяться, что ОпенБрокер всё таки обновит сервер.
ps мой билд клиента 1340
También tengo una pregunta, aunque un plan un poco diferente, y también me pregunto si la información transmitida por los ticks es correcta.
Una pregunta sobre volúmenes reales.
Si solicita información sobre los ticks del indicador, entonces el volumen real va allí en la matriz de volumen []. Y, en teoría, si obtiene información de los ticks, entonces el volumen acumulado por vela debería coincidir con el valor de la matriz volume[].
Aquí hay un ejemplo de código de prueba:
No nos apeguemos a las banderas por ahora, y supongamos que cada marca recibida cambia el volumen total de sVol (aunque, hasta donde yo sé, este no es el caso).
Estamos esperando la formación de una nueva vela y miramos las entradas en el diario. Apertura de corredor, cuenta real, compilación 1340, RTS-6.16:
Y así sucesivamente, el volumen real del indicador será mucho mayor que el acumulado. Esto plantea algunas preguntas para los desarrolladores:
1. ¿El volumen obtenido de la matriz volume[] de la función OnCalculate() debe ser el mismo que el volumen acumulado obtenido de los ticks? Mi opinión, por supuesto, debería, de lo contrario, ¿por qué indicarla en ticks?
2. ¿Es correcto usar la función OnCalculate() para acumular el volumen, o es mejor obtener el volumen a través de OnBookEvent()? La ayuda dice:
El evento Calcular se genera solo para indicadores inmediatamente después de enviar el evento Init y ante cualquier cambio en los datos de precios. Manejado por la función OnCalculate.
entonces, en teoría, es correcto, pero me gustaría escuchar un comentario al respecto.
3. Los resultados de la prueba se muestran SIN análisis de banderas. Si analizamos las banderas, entonces, según tengo entendido, debe tomar volúmenes de ticks con banderas 24 (cambio simultáneo en el último y el volumen):
Pero en este caso, el volumen acumulado será aún menor. Me gustaría escuchar los comentarios de los desarrolladores sobre cómo analizar correctamente los ticks ahora (ya que todos los campos están registrados) y si las banderas están implementadas correctamente. La pregunta sobre la corrección de la implementación surgió porque no noté marcas con banderas:
El archivo del indicador también está en la aplicación.