Error nº 1 al modificar los pedidos - página 4
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
Boris, supongamos que es así... Asumiendo. Pero, si la función reenvía una orden para modificarla, el significante debe ser modificado. Y conmigo no se modifica en absoluto. Incluso si miramos el registro en la bitácora, lo que vemos es esto:
¿Por qué se envía el pedido? Si no tuviera los parámetros correctos, la función habría explotado... Es como OK... ...fue enviado. Luego resultó que había un error... ¿Cuál es la lógica detrás de esto?¡Acaba de encenderse! Victor, si "ok", significa que algún parámetro ha cambiado, pero el error 1 significa que algún parámetro fue declarado para cambiar, pero resultó ser sin cambios. Por eso hay que corregir su lógica para evitar estos casos, ¡y todas estas imprecisiones darán lugar a recotizaciones y a un montón de errores en el mercado real!
Ya sabes que yo no uso este estilo de programación, que todo está disperso. Escribo el programa como un guión lógico, todos los eventos se desarrollan secuencialmente, y todo está siempre a mano con todas las condiciones sin tener que rebuscar. Y utilizo funciones externas para realizar la acción final y comprobar los errores.
Pero en tu caso, no está claro para los no iniciados qué tienes y dónde está marcado, todo está oculto, ¡y tienes que adivinar si has marcado el requisito previo o no! Son muchas palabras, como las mías ahora, pero su programa no consigue que se entienda. Debe ser claro y conciso.
Boris, me doy cuenta, por supuesto, de que no tengo todo en el mismo sitio. Pero los parámetros de entrada justo antes de la función de modificación están acoplados. Acabo de lanzar una captura de pantalla de la misma. Hay PLO actuales y nuevos, SL y TP. Y todos son diferentes. ¿Por qué debería entrar en detalles si todo está cerca? Si no está impreso, y puedes ver que los parámetros son diferentes, significa que efectivamente son diferentes. ¿O tal vez tampoco deberías confiar en la impresión?
Y antes de eso, como he mostrado arriba, hay una prueba:
¿Cómo puede ser más específico? Hay un par de payasos encima que han empezado a inventarse historias. Al parecer, no pudieron o no quisieron entender lo que les pedía. Así que se ríen sin razón. Pero la cuestión es interesante.
Si insertamos, por ejemplo, un parámetro de otro tipo o una cantidad errónea en OrderModify(), los errores se producen de inmediato. Y aquí se ejecuta, dice como OK, pero luego resulta que ningún parámetro fue cambiado.
La pregunta es: ¿cómo sabemos qué es lo que está mal allí? He expuesto mi función. Todo debería estar claro ahí. Aquí está:
He comentado a propósito todas las líneas. Puedes estropear el código. Si tiene algún comentario, por favor ayude.
Boris, me doy cuenta, por supuesto, de que no tengo todo en el mismo sitio. Pero los parámetros de entrada justo antes de la función de modificación están acoplados. Acabo de lanzar una captura de pantalla de la misma. Hay PLO actuales y nuevos, SL y TP. Y todos son diferentes. ¿Por qué debería entrar en detalles si todo está cerca? Si no está impreso, y puedes ver que los parámetros son diferentes, significa que efectivamente son diferentes. ¿O tal vez tampoco deberías confiar en la impresión?
Y antes de eso, como he mostrado arriba, hay una prueba:
TodoLo siento, no soy capaz de entender esto ya que no veo ninguna condición en el bucle que asegure que los parámetros de la orden no se confundan entre sí.
La presencia de un error le indica que está cometiendo un error lógico en alguna parte. Pero también dice que el programa funciona, ¡pero nos interesa la calidad del programa!
Lo siento, no soy capaz de entender esto ya que no veo ninguna condición en el bucle que garantice que los parámetros de la orden no se confundan entre sí.
La presencia de un error le indica que está cometiendo un error lógico en alguna parte. Pero también dice que el programa funciona, ¡pero nos interesa la calidad del programa!
Todas las operaciones con órdenes tienen lugar en un bucle. Aquí es donde se llama al método fOrderModify(), cuyo código he citado anteriormente:
Puedes ver todo allí... También puedes ver que después de cada iteración del bucle se borra el error. Así, se garantiza que un error en el orden anterior, si lo hubiera, no saltará al siguiente (me refiero a su valor, claro).
¿Cuánto más fácil puede ser? Es tan simple...
He encontrado un mensaje.
Es el mismo error de la terminal. Nunca había tenido un bicho así. Nunca he intentado cambiar los 3 parámetros (OOP, SL y TP) de las órdenes pendientes. Pero he tenido que hacerlo. Y me he topado con un error.
Veo que, por ejemplo, el precio de apertura y el Stop Loss no han cambiado y en su lugar obtenemos los mismos valores, pero los Take Points han cambiado. ¿También provoca el error? Luego resulta que la documentación está torcida. ¿Y este punto no se sostiene o qué?
Encontré un mensaje.
Es el mismo error de la terminal. Nunca había tenido este tipo de cosas. Nunca he intentado cambiar los 3 parámetros (OOP, SL y TP) de las órdenes pendientes. Pero he tenido que hacerlo. Y me he topado con un error.
Veo que, por ejemplo, el precio de apertura y el Stop Loss no han cambiado y en su lugar obtenemos los mismos valores, pero los Take Points han cambiado. ¿También provoca el error? Luego resulta que la documentación está torcida. ¿Y este punto no se sostiene o qué?
¿Compruebas también la distancia en cada tic? Hace tiempo que adopté la regla de abrir las órdenes en la apertura de la barra de TF y de modificarlas y cerrarlas sólo en la apertura de la barra de M1. El código anterior me recuerda a un informe de progreso, que parece contener todo, ¡pero nada concreto! ¡No veo un bucle, en el que se definen todas las acciones por condiciones específicas! Sólo veo un bucle que me dice que no hay que modificar nada, entonces no modifiques y no habrá errores.
Tenga en cuenta el importante punto de Renat de que sus errores pueden provenir de la confusión sobre lo que hay que hacer globalmente y lo que hay que hacer localmente, y los errores son siempre los segundos, ¡los anteriores se restablecen sin que usted intervenga con la salida de la función!
¡¿También compruebas la distancia en cada tictac?!
¡No! Sólo permito modificaciones si se cumple una condición. En este caso, la condición para la modificación es cambiar los niveles calculados. Así de fácil:
¿Simple? Sólo....
Hace tiempo que establecí la regla de abrir órdenes en la apertura de una barra en TF, y de modificar y cerrar sólo en la apertura de una barra en M1. El código anterior me recuerda a un informe de progreso, que parece contener todo, ¡pero nada en concreto! ¡No veo un bucle, en el que se definen todas las acciones por condiciones específicas! Sólo veo un bucle que me dice que no hay que modificar nada, entonces no modifiques y no habrá errores.
Yo también tenía pensamientos similares, para modificar sólo en la apertura de M1, y, esto es aplicable si la modificación se hace por un valor predefinido. Pero hay situaciones en las que no necesito comprobar estos datos en M1. Por ejemplo, tengo un stop tirado a un nivel ya calculado. Entonces, como he mostrado arriba, tengo una comprobación en la función OnInit():
Es decir, si el nivel ha cambiado... modifica. Así se evitan intentos de modificación innecesarios. Por así decirlo, modificación por señal y no por temporizador. ¿Entendido aquí?¡No veo un bucle donde se definan todas las acciones por condiciones específicas! Sólo veo un bucle que me dice que no hay que modificar, luego simplemente no se modifica y no hay errores.
Lo tengo todo desnudo ahí fuera. Qué es lo que no hay que entender... :(
Tenga en cuenta el importante punto de Renat de que sus errores pueden provenir de la confusión sobre lo que hay que hacer globalmente y lo que hay que hacer localmente, y los errores son siempre los segundos, ¡los anteriores se restablecen sin que usted intervenga con la salida de la función!
Y parece que no se solucionó ni se va a solucionar. ¿Quizás los desarrolladores son perezosos? Si no estoy trabajando correctamente con errores, alguien, incluyendo Renat podría haber hurgado en el código, y no sólo decir que lo tengo mal.
Después de todo, si los valores nuevos y actuales de los parámetros a modificar se imprimen antes de la función de modificación, está claro que estos valores están ahí. ¿Por qué ir más arriba en algún lugar? Hay valores, está claro que no hay errores (imprimí allí para los errores). Significa que todo está bien en la lógica. Así que el fallo en la función de modificación.
¡No! Sólo permito modificaciones si se cumple una condición. En este caso, la condición para la modificación es cambiar los niveles calculados. Así de fácil:
¿Simple? Sólo....
Yo también tenía pensamientos similares, para modificar sólo en la apertura de M1, y, esto es aplicable si la modificación se lleva a cabo por un valor predeterminado. Pero hay situaciones en las que no necesito comprobar estos datos en M1. Por ejemplo, tengo un stop tirado a un nivel ya calculado. Entonces, como he mostrado arriba, hay una comprobación en la función OnInit():
Es decir, si el nivel ha cambiado... modifica. Así se evitan intentos de modificación innecesarios. Por así decirlo, modificación por señal y no por temporizador. ¿Entendido aquí?He descolgado todo allí. Qué es lo que no hay que entender... :(
Este problema, como he descubierto, no sólo me ocurre a mí. He aquí un ejemplo...Y parece que no se ha resuelto ni se va a resolver. ¿Quizás los desarrolladores son perezosos? Si no estoy trabajando correctamente con errores, alguien, incluyendo Renat podría hurgar en el código, y no sólo decir que lo tengo mal.
Después de todo, si los valores nuevos y actuales de los parámetros a modificar se imprimen antes de la función de modificación, está claro que estos valores están ahí. ¿Por qué ir más arriba en algún sitio? Hay valores, está claro que no hay errores (imprimí allí para los errores). Significa que todo está bien en la lógica. Así que el fallo está en la función de modificación.
Ya he visto este ejemplo. Pero tenemos que aplicarnos a cualquier condición, hasta que no haya nada mejor. Su código no me convence. Voy a almorzar ahora, luego te daré un ejemplo de un bucle que funciona bien para la configuración de SL, la traducción a B/S y el rastreo de una sola llamada a la función de modificación, donde los errores se manejan, si de repente se producen en el trabajo, no se producen en el probador.
¿Quiere la función Modify()?
Al fin y al cabo, si los valores nuevos y actuales de los parámetros a modificar se imprimen antes de la función de modificación, está claro que esos valores están ahí. ¿Por qué ir más arriba en algún lugar? Hay valores, está claro que no hay errores (imprimí allí para los errores). Significa que todo está bien en la lógica. Así que el fallo en la función de modificación.
Víctor, ¿por qué has modificado el SL y el TP en las posiciones pendientes? En general, tiene sentido fijar el SL sólo después de abrir una posición, y el TP después de la transferencia del SL al B/S. Entonces, ¿por qué molestar tanto al servidor para nada y por qué hay que pasar por todas estas molestias?
Hay que minimizar y simplificar el código, para que funcione de forma rápida y clara, ¡y luego será más fácil retocarlo por los caprichos del mercado! Piense cuidadosamente en todos los matices relacionados con las realidades del mercado.