Errores, fallos, preguntas - página 492
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
Absolutamente, exactamente en todos ellos.
Tanto como lo disponible, tanto como lo recibido. Esa es la forma de entenderlo. Comprueba la profundidad disponible del historial. Asegúrese de que los datos están disponibles antes de solicitarlos. ¿Qué compilación tienes? Recientemente se ha corregido un error con la copia de los plazos mensuales, puede que sea esto.
Así que no se comprueba bien o el Asesor Experto NO es multidivisa, sólo puede funcionar en diferentes símbolos. El razonamiento es sencillo: saber que las garrapatas llegan a diferentes símbolos en diferentes momentos. Por lo tanto, si un EA está onTick EURUSD (por ejemplo), y comprueba GBPUSD o incluso sólo los cambios de tick de GBPUSD en lugar de EURUSD, el resultado será diferente. En particular, una barra formada en el EURUSD puede ocurrir antes de la formación de una barra con el mismo tiempo en el GBPUSD. Si usted opera con el GBPUSD dos veces en la misma barra: la barra anterior del GBPUSD seguirá siendo considerada como una nueva barra (cero). En cuanto a los indicadores multidivisa, todo está claro. Aprende lo básico.
Qué carajo es la matemática, un tick ha entrado en 1 par, pero si el segundo tick se retrasa y f...
es decir, necesitamos el precio en el momento de la aparición de una nueva barra y los ticks
No juega un papel en la aparición de una nueva barra en todos los símbolos, pero es de
La estrategia depende, si no eres un scalper
Me gustaría preguntar al equipo de MQ una vez más si hay planes para llevar la función iCustom() a un estado de trabajo.
Actualmente, los desarrolladores del Asesor Experto no pueden ofrecer una solución universal utilizando iCustom(),
donde el cliente podría especificar el nombre de un indicador externo utilizado por el Asesor Experto.
Para ello, el cliente necesita tener el código fuente del Asesor Experto, así como introducir manualmente el nombre de cada indicador en el código del Asesor Experto, lo cual es bastante incómodo, por decirlo suavemente.
También existe el problema de la obligatoriedad de indicar explícitamente los valores de las casillas del buffer indicador.
Si no se asigna explícitamente ningún valor (vacío o no vacío) a las celdas del búfer del indicador en el texto del indicador, la función iCustom() puede rellenar las celdas indicadas en el Asesor Experto con
con cualquier basura. Creo que esta operación de la función no puede considerarse correcta.
Me gustaría preguntar al equipo de MQ una vez más si hay planes para llevar la función iCustom() a un estado de trabajo.
Actualmente, los desarrolladores del Asesor Experto no pueden ofrecer una solución universal utilizando iCustom(),
donde el cliente puede especificar el nombre de un indicador externo utilizado por el Asesor Experto.
Para ello, el cliente necesita tener el código fuente del Asesor Experto, así como introducir manualmente el nombre de cada indicador en el código del Asesor Experto, lo cual es bastante incómodo, por decirlo suavemente.
Puede pasar un nombre dinámico del indicador llamado en iCustom, pero el conjunto de parámetros de cada indicador personalizado es diferente.
Desgraciadamente, no conocemos una solución universal a la pregunta "¿cómo podemos implementar de forma segura la llamada sin tocar el código sin saber a qué y con qué parámetros se va a llamar?
Si he entendido bien, usted quiere hacer un sistema de plugin, cuando un usuario de terceros establece cualquier nombre del indicador con parámetros (por ejemplo, "MyIndicator(10,20,50,100)") en la configuración de EA. Para este caso con un formato rígido del nombre, puede analizar la cadena usted mismo, formar un bloque de parámetros e implementar una llamada dinámica de iCustom con un conjunto diferente de parámetros como clase envolvente. En otras palabras, se ocultarán en su interior varias variantes de la llamada iCustom con diferentes conjuntos/número de parámetros.
También existe el problema de la obligatoriedad de indicar explícitamente el valor de las casillas del buffer indicador.
Si no se asigna explícitamente ningún valor (vacío o no vacío) a la celda del búfer del indicador en el texto del indicador, la función iCustom() puede rellenar las celdas indicadas en el Asesor Experto con
con cualquier basura. Creo que esta operación de la función no puede considerarse correcta.
Es una desfachatez y franca pereza del promotor no llenar el búfer que se le dio a su completa disposición.
El sistema en tiempo de ejecución no sabe cómo se utiliza el búfer del indicador y no tiene derecho a llenarlo con algunos valores, especialmente durante los momentos de sobreasignación masiva (paginación o actualización de gráficos). El indicador es necesariamente notificado sobre todos los casos en los que se requiere recalcular a través de la función OnCalculate(...,const int prev_calculado,...) y el parámetro prev_calculado.
En iCustom, se puede pasar un nombre dinámico del indicador a llamar, pero cada indicador personalizado tiene su propio conjunto de parámetros.
Desgraciadamente, no conocemos una solución universal a la pregunta "¿Cómo podemos implementar de forma segura la llamada sin perturbar el código, sin saber qué y con qué parámetros se va a llamar?
Si he entendido bien, usted quiere hacer un sistema de plugin, cuando un usuario de terceros establece cualquier nombre del indicador con parámetros (por ejemplo, "MyIndicator(10,20,50,100)") en la configuración de EA. Para este caso con un formato rígido del nombre, puede analizar la cadena usted mismo, formar un bloque de parámetros e implementar una llamada dinámica de iCustom con un conjunto diferente de parámetros como clase envolvente. En otras palabras, se ocultarán en su interior varias variantes de la llamada iCustom con diferentes conjuntos/número de parámetros.
Por la problemática necesidad de cambiar el código, me refería a la necesidad de especificar explícitamente el nombre del indicador durante las pruebas
en el formato #property tester_indicator "Nombre.ex5", pero no un número diferente de parámetros del indicador.
Los indicadores se pueden utilizar con los parámetros por defecto, seleccionando únicamente el número de búferes de los indicadores con la señal correspondiente.
Esto es una desfachatez y una pura pereza del promotor para no rellenar el buffer que se le dio a su completa disposición.
El sistema en tiempo de ejecución no sabe cómo se utiliza el búfer del indicador y no tiene derecho a llenarlo con algunos valores, especialmente durante los momentos de sobreasignación masiva (paginación o actualización de gráficos). El indicador es necesariamente notificado sobre todos los casos de necesidad de recálculo a través de la función OnCalculate(...,const int prev_calculado,...) y el parámetro prev_calculado.
¿Es realmente difícil asignar Empty_Value a las celdas no utilizadas en iCustom() en lugar de obstruirlas con basura de la pila?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Tenga en cuenta que el valor real de las celdas del buffer sigue siendo un Vacío. Es iCustom() el que hace la manipulación.
Por necesidad problemática de cambios en el código, me refería a la necesidad de especificar explícitamente el nombre del indicador durante las pruebas
en el formato #property tester_indicator "Nombre.ex5", pero no un número diferente de parámetros del indicador.
Resolveremos la cuestión más adelante: hay matices.
¿Es realmente difícil asignar Empty_Value a las celdas no utilizadas en iCustom() en lugar de llenarlas con basura de la pila?
https://www.mql5.com/ru/forum/1111/72233#comment_72233
Esto no debería hacerse. Vuelve a leer mi respuesta, por favor.
La razón por la que iCustom() asigna valores arbitrarios a esas celdas de la memoria intermedia que en realidad no están llenas de nada no me queda clara, ni tampoco por qué no se puede evitar de ninguna manera.
Supongo que tiene algo que ver con la asignación de memoria para el correspondiente array de datos del buffer del indicador.
Esta operación de iCustom(), cuando es imposible determinar el origen y la veracidad de los datos, me parece inadmisible y crea riesgos adicionales para el usuario.
Si iCustom() asigna valores arbitrarios e inconsistentes con los reales a las celdas del buffer de todos modos,
¿por qué no asigna valores iguales a Empty_Value a estas celdas como está implementado en MT4?
Así, al menos, su situación quedaría clara.
pero de esta manera
hay un redondeo, ¿sigue diciendo eso?
Yo no discuto.
pero de esta manera
hay redondeo todavía escribe, debe ser así?