Errores, fallos, preguntas - página 3121
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
Si lo sabes, por favor, dímelo. Si subes una nueva versión de un código existente a CodeBase, ¿se restablecerá la prohibición de votar para los desarrolladores anteriores y podrán volver a votar por la nueva versión? Yo mismo lo dudo mucho, pero si fuera posible sería justo restablecer la calificación anterior en lugar de la nueva (que hipotéticamente se supone que no es inferior a la anterior), ya que el código está evolucionando y la nueva versión podría satisfacer al votante en mayor medida, mientras que la antigua calificación para el código anterior quedaría invalidada. (Es cierto que, a medida que la funcionalidad crece, el código también lo hace, por lo que puede haber nuevos errores y fallos, aún más molestos. Todo puede pasar... y la nueva puntuación puede ser más baja, pero me parece bien).
Deje de rasgarse las vestiduras por la baja calificación de sus ...códigos. Si una persona da a su código una puntuación de 1, no significa que sea lo que es. Pues bien, reescríbelo al menos 100 veces... y las 100 veces este código será calificado así. ¿Es tan difícil de entender?
Deje de rasgarse las vestiduras por la baja calificación de sus ...códigos. Si una persona da a su código una puntuación de 1, no significa que sea lo que es. Pues bien, reescríbelo al menos 100 veces... y las 100 veces este código será calificado así. ¿Es tan difícil de entender?
Quizá su currículum refleje la realidad del voto y eso es triste. Pero no estoy triste por mí - esas estrellas virtuales no se pueden tomar con té y meter en mi cartera, estoy frustrado con el concepto de la forma en que se presentan los productos a los nuevos usuarios, preocupándose por ellos específicamente. Si no hay una clasificación creíble, los usuarios no podrán buscar eficazmente el producto que desean basándose en el criterio de "ordenar por clasificación". Resulta que el sistema de calificación es un sistema vacío y uno se queda buscando el producto adecuado por su nombre/descripción en lugar de confiar en el inútil número de estrellas. De lo contrario, seguirán pescando cosas... lo que flota en la superficie (merecidamente o no) y lo que realmente necesitan será pasado por alto. Sólo estaba sugiriendo que esto debería cambiarse para ser más reflexivo. Pero si nadie va a luchar contra esa realidad, me lavo las manos.
Su resumen puede reflejar la realidad del voto, y eso es decepcionante. Pero no es por mí por quien estoy triste - esas estrellas virtuales no se pueden tomar con té y poner en mi cartera, estoy decepcionado por el concepto de la forma en que se presentan los productos a los nuevos usuarios, preocupándose precisamente por ellos. Si no hay una clasificación creíble, los usuarios no podrán buscar eficazmente el producto que desean basándose en el criterio de "ordenar por clasificación". Resulta que el sistema de calificación es un sistema vacío y uno se queda buscando el producto adecuado por su nombre/descripción en lugar de confiar en el inútil número de estrellas. De lo contrario, seguirán pescando cosas... lo que flota en la superficie (merecidamente o no) y lo que realmente necesitan será pasado por alto. Sólo estaba sugiriendo que esto debería cambiarse para ser más reflexivo. Pero si nadie va a luchar contra esa realidad, me lavo las manos.
Echemos un vistazo a su código.
Cada tic desencadena el acceso a las variables globales, 4 peticiones a la vez.
De esto se deduce que NO puedes usar este código en tu máquina personal, puedes usarlo en otro lugar, donde no te sobra el disco duro.
En el bucle en un bucle durante la búsqueda 3 veces ArraySize debe ser llamado , mientras que hay dos de ellos, esto es una carga adicional en el procesador, esto también es indeseable, el rendimiento del código cae.
DeInite elimina los objetos de una manera extraña, no hay nada malo aquí, pero es un mal ejemplo para los principiantes, si lo haces normalmente, debes introducir un prefijo al crear los objetos yeliminarlos sin excesivos recálculos.
Le doy 2 puntos a su código.
Para el trabajo del indicador - no sé, no lo he ejecutado.
¿Objetivo?
Bueno, echemos un vistazo a su código.
En cada tic se activa el acceso a las variables globales, 4 peticiones a la vez
De esto se deduce que NO puedes usar este código en tu máquina personal, puedes usarlo en otro lugar, donde no te sobra el disco duro.
En un bucle durante la búsqueda es necesario llamar a ArraySize 3 veces , mientras que hay dos de ellos, esto es una carga adicional en el procesador, esto también es indeseable, el rendimiento del código cae.
DeInite elimina los objetos de una manera extraña, no hay nada malo aquí, pero es un mal ejemplo para los principiantes, si lo haces normalmente, debes introducir un prefijo al crear los objetos yeliminarlos sin excesivos recálculos.
Le doy 2 puntos a su código.
Para el trabajo del indicador - no sé, no lo he ejecutado.
¿Objetivo?
1. En cada tick hay una llamada al GP, por lo que en cada tick, y también en cada reinicialización (por ejemplo, transiciones a través de TFs) el código principal y más pesado enOnCalculate() no se ejecuta, y el indicador funciona más rápido. El cálculo de los nuevos datos - sólo con la aparición de una nueva barra baja D1, que es mucho más raro, que en cada tick.
2. He trabajado con detenimiento y minuciosidad sobre el código, pero he dejado algunas operaciones de comparación innecesarias en if() porque sé con seguridad que no afectará al rendimiento.
3. Lo de que no debe ser, es muy exagerado. Puedes descargarlo y comprobarlo por ti mismo: el indicador vuela.
4. No sabía que los GPs se descargan en el AF y luego se leen desde la misma ubicación cada vez que se accede a ellos en una sesión de MT5 en marcha. Sigo pensando que se leen de la LCD a la RAM una vez que arranco el terminal y viven allí, y el indicador accede a ellos en la RAM, no a la LCD.
5. No creo que ArraySize() sea una función cara. Y aunque sea caro, no lo notarás en este código en particular. Probablemente optimizaría esta función en mi primer indicador, donde se utiliza con bastante frecuencia, mientras que el indicador en sí es mucho más complejo y requiere muchos recursos.
6. En OnDeinit() uso:
donde sólo hay eliminación por el prefijo "l" (los nombres " etiqueta" y " línea" se utilizaron al crear los objetos.
7. Ahora ha hecho lo que debería hacer un usuario que ha descargado y entendido el código. Usted ha encontrado los defectos - esto también es parte del aprendizaje de MQL.
8. Conclusión: 1.) mi principal argumento de código no ideal de este indicador - la simplicidad, la compacidad y la velocidad... además de un trabajo perfecto; 2.) mi segundo argumento principal del código imperfecto: la falta de análogos, incluso malos, en términos de velocidad y versatilidad (véase la discusión de los originales de otros) y la disponibilidad de mejoras en comparación con el original, que, por cierto, es estrecho y no se pliega en bucles compactos en términos de gran número de bloques repetidos de manera similar.
9. A pesar del punto 7, no has entendido realmente el código de otra persona. Su puntuación de 2 es demasiado baja. Todavía no le recomiendo que evalúe los productos de software por su código. No voy a decir nada sobre la objetividad porque es imposible esperar ninguna objetividad de un solo usuario. Una estimación objetiva (calificación) sólo es posible como suma de las estimaciones de varios usuarios cuerdos y, desde luego, no tiene que ser necesariamente alta.
1. En cada tick hay una referencia al GP para que en cada tick, así como en cada reinicialización (por ejemplo, transiciones a través de TFs) no se ejecute todo el código principal y más pesado enOnCalculate(), y el indicador funcione más rápido. Cálculo de nuevos datos - sólo con la aparición de una nueva barra baja D1, que es mucho más rara, que en cada tick.
2. He revisado el código con detenimiento, pero he dejado algunas operaciones de comparación redundantes en if() porque sé con certeza que no afectará al rendimiento.
3. Sobre el MUST - muy exagerado. Puedes descargarlo y comprobar por ti mismo que el indicador vuela.
4. No sabía que los GPs se vuelcan al disco duro y luego se leen desde allí cada vez que se accede a ellos dentro de una sesión de MT5 en ejecución. Sigo pensando que se leen del HD a la RAM una vez que arranco el terminal y viven ahí, y el indicador accede a ellos en la RAM, no al HD.
5. No creo que ArraySize() sea una función cara. Y aunque sea caro, no lo notarás en este código en particular. Probablemente optimizaría esta función en mi primer indicador, donde se utiliza con bastante frecuencia, mientras que el indicador en sí es mucho más complejo y requiere muchos recursos.
6. En OnDeinit() uso:
donde sólo hay eliminación por el prefijo "l" (los nombres " etiqueta" y " línea" se utilizaron al crear los objetos.
7. Ahora ha hecho lo que debería hacer un usuario que ha descargado y entendido el código. Usted ha encontrado los defectos - esto también es parte del aprendizaje de MQL.
8. En resumen: 1.) mi principal argumento de código no ideal de este indicador - la simplicidad, la compacidad y la velocidad... 2.) mi segundo argumento principal del código imperfecto - la ausencia de análogos en términos de velocidad y versatilidad (véase la discusión del original de otra persona) y la disponibilidad de mejoras en comparación con el original, que, por cierto, es estrecho y no se dobla en bucles compactos en términos de gran número de bloques repetidos de manera similar.
9. A pesar del punto 7, no has entendido realmente el código de otra persona. Su puntuación de 2 es demasiado baja. Todavía no le recomiendo que evalúe los productos de software por su código. No voy a decir nada sobre la objetividad porque es imposible esperar ninguna objetividad de un solo usuario. Una estimación objetiva (calificación) sólo es posible como suma de las estimaciones de algunos usuarios cuerdos y no tiene que ser necesariamente alta.
La eliminación por prefijo es la siguiente: ObjectsDeleteAll(0, "pref_"); // "pref_label" y " pref_line"
Añadir al menos la primera línea a OnCalculate para que se dirija en una nueva barra y no en cada tick como es ahora
Eliminar por prefijo, es así: ObjectsDeleteAll(0, "pref_"); // "pref_label" y " pref_line"
Añadir al menos si la primera línea a OnCalculate, para que la referencia sea en una nueva barra, y no en cada tick, como es ahora
Por cierto, respecto al punto 7: me he encontrado con errores incluso en la documentación de MQL5, que no se corrigen desde hace muchos años.
El borrado por prefijo es así: ObjectsDeleteAll(0, "pref_"); // "pref_label" y " pref_line"
Borrarlo de la forma que sugieres no es razonable porque el comienzo del prefijo es dinámico: o bien{D1}, o bien {W1}, o bien{MN1} y luego viene un prefijo inmutable como " l...". Puede intercambiar los prefijos dinámicos y estáticos y eliminarlos con seguridad según su versión. Pero no es razonable porque es inconveniente tomar la información como "R1{D1}", mientras que es más conveniente usar "{D1} R1". Lo pensé todo hace mucho tiempo e hice exactamente lo que hice.
No hay una forma sensata de eliminarlo de la forma que sugieres, porque el comienzo del prefijo es dinámico: o bien{D1} o bien {W1} o bien{MN1}, y luego hay un prefijo inmutable como " l...". Puede intercambiar los prefijos dinámicos y estáticos y eliminarlos con seguridad según su versión. Pero no es razonable porque es inconveniente tomar la información como "R1{D1}", mientras que es más conveniente usar "{D1} R1". Lo pensé todo hace mucho tiempo e hice exactamente lo que hice.
DrawTheLine("pref"+line_types[lt], StAun así, sí, en principio podrías hacerlo. Me expliqué con gallardía arriba, pensando en ese momento en:
no sobre los nombres de los objetos. El gráfico lee exactamente lo que se establece conOBJPROP_TEXTpara las etiquetas, pero los nombres de los objetos pueden firmarse de forma menos legible, porque están ocultos y rara vez se leen.
Por otro lado, en la "Lista de objetos" (Ctrl+b) es mejor ver los nombres de los objetos legibles, por lo que mi manera es más preferible. Además, hay casos en los que los nombres de los objetos tienen que ser extremadamente largos, por lo que los"pref_" adicionales serán completamente inaceptables.Aun así, sí, en principio podrías hacerlo. Me expliqué con gallardía arriba, pensando en ese momento en:
no sobre los nombres de los objetos. El gráfico lee exactamente lo que se establece conOBJPROP_TEXTpara las etiquetas, pero los nombres de los objetos pueden firmarse de forma menos legible, porque están ocultos y rara vez se leen.
Por otro lado, en la "Lista de objetos" (Ctrl+b) es deseable ver nombres de objetos legibles, por lo que mi versión sigue siendo preferible. Además, hay casos en los que los nombres de los objetos tienen que ser extremadamente largos, por lo que un"pref_" extra sería completamente inaceptable.y si alguien todavía tendrá un programa con objetos gráficos, su tipo de prefijo "l" < donde sólo se elimina por el prefijo "l" (los nombres "etiqueta" y "línea" se utilizaron cuando los objetos fueron creados >
Matará todos los objetos que empiecen por"l" en un programa de terceros. Esta no es una buena solución