Errores, fallos, preguntas - página 2342
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
¿Los recursos están limitados a este tamaño?
Por eso tiene más sentido condensar los datos que se transmiten.
En ese sentido MT4 era mucho más sabio que MT5 - no había caída del programa y se podía analizar el LastError.
En primer lugar: seguir ejecutando el programa después de un error crítico irrecuperable no es sabiduría, sino estupidez.
Segundo: No he llegado a PrintError() en MetaTrader 4 765x32 después de ejecutarlo
Tercero: Si se elimina strict, se ha llegado a él, pero GetLastError() devuelve 0, por lo que no está claro qué analizar
¿Cómo notificar al usuario sobre la detención del EA?
En este sentido MT4 era mucho más sabio que MT5 - no había caída del programa y se podía analizar el LastError.
Y al acceder a un array, ¿no es lógico comprobar el índice de acceso?
En primer lugar: es una estupidez, no una sabiduría, seguir ejecutando el programa después de que se produzca un error crítico irrecuperable.
En segundo lugar, después de ejecutar esto en MetaTrader 4 765x32, PrintError() nunca ocurrió.
En tercer lugar, si se elimina strict, devolverá 0, pero GetLastError(), por lo que no está claro qué analizar.
No había ninguna tarea para demostrar que MT4 es mejor que MT5. Tenía que resolver un problema práctico.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Bibliotecas: HistoryTicks
fxsaber, 2018.12.10 13:55
Recibir un mensaje de que el EA se ha detenido debido a una matriz fuera de rango(no es culpa del autor del EA). Por ejemplo, por falta de memoria u otro fallo. Esto significa que usted sabrá de inmediato que el EA se ha detenido anormalmente, en lugar de notarlo accidentalmente unas horas más tarde.
Es desagradable cuando el Asesor Experto se ha detenido, pero no se informa de ninguna manera.
Y al acceder a un array, ¿no sería lógico comprobar el índice de acceso?
No es lógico.
Por eso es más razonable condensar los datos que se transmiten.
Comprobado, 60Mb se escriben fácilmente (MT4/5) en Recursos. Así que si hay un límite, es más alto.
Un punto pequeño, pero aún así.
Al enviar al almacenamiento - el primer panel "Fijación" - funciona bien, y el segundo, la confirmación, en mi primer caso, no espera la tecla OK, pero inmediatamente sale, y en segundo lugar - no muestra todos los archivos enviados. Sin embargo, lo he comprobado: los archivos se envían con normalidad.
¿Soy yo?
Parece que es correcto - cuando después de enviar una lista de archivos enviados se muestra con una confirmación de que todo fue bien.
No tiene sentido.
¿Y por qué?
Me parece que no hay que comprobar el índice donde, lógicamente, no puede aparecer un índice que sobrepase los límites del array. E incluso en este caso deberías usar ASSERT, por si acaso.
Y en aquellos lugares donde el índice depende de acciones previas relacionadas con parámetros externos, citas y acciones del usuario, la comprobación de la referencia al índice debería ser obligatoria.
En su opinión, ¿no es así?
¿Y por qué?
Me parece que no hay necesidad de comprobar el índice cuando, basándose en la lógica del programa, no hay forma de que un índice aparezca fuera del array.
Estoy de acuerdo.
E incluso en este caso tendrás que usar ASSERT por si acaso.
No estoy de acuerdo ya que la legibilidad del código se verá muy afectada.
En aquellos lugares en los que el índice depende de acciones previas relativas a parámetros externos, cotizaciones y acciones del usuario, la comprobación del índice de manipulación debe ser obligatoria.
No entiendo a qué nos referimos aquí con parámetros externos. Cada vez que compruebe que ArrayResize o ArrayCopy se han completado con normalidad y no se ha agotado la memoria trivial, hinchará el código a través de ASSERT, y esto es realmente un lío. Si no lo compruebas, obtendrás una parada imperceptible del Asesor Experto. Hasta ahora, sólo he encontrado una solución: sustituir ArrayResize y ArrayCopy.
¿Quién está en el camino?
ChartSaveTemplate(chart_id,"\\Files\\MyPreferredTemplates\\cewl.tpl");
La función no crea una carpeta, sólo escribe una plantilla si ya existe una carpeta .... Si la carpeta no existe, error 4112
Así que las carpetas deben estar preparadas de antemano...
Es interesante, la función FileOpen no puede crear una carpeta en la carpeta de plantillas y la función ChartSaveTemplate no crea directorios...
Es decir, si quiere guardar las plantillas en subcarpetas, cree manualmente las carpetas ....
sin memoria
al buscar GlobalVariables
¿puede surgir?