Discusión sobre el artículo "Biblioteca para el desarrollo rápido y sencillo de programas para MetaTrader (Parte XXVII): Trabajando con las solicitudes comerciales - Colocación de órdenes pendientes" - página 3
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
No soy yo quien no quiere comunicar sobre el tema, pero usted no ha entendido la esencia de este tema.
Has decidido que no entiendo que cada tipo de consulta diferida necesita su propia solución. Todas las consultas tienen sus propias propiedades y una solución común es imposible. Para los pedidos una solución es una, para la solicitud repetida de algunos datos - otra. En los últimos dos artículos estamos trabajando en una solución para los pedidos. El próximo también tratará de ello. Mi opinión es que es demasiado largo.
3 artículos para resolver una solicitud pendiente SOLO para pedidos, dos de los cuales no completan nada.... Aunque en realidad (no en la forma) la solución para la solicitud de pedido pendiente es bastante fácil.
Decidiste que no entiendo que cada tipo de consulta pendiente necesita una solución diferente. Todas las consultas tienen sus propias propiedades y una solución común es imposible. Una solución para los pedidos es una solución, otra para la solicitud repetida de algunos datos. En los dos últimos artículos estamos trabajando en una solución para los pedidos. El próximo también tratará sobre ello. Mi opinión es que es demasiado largo.
3 artículos para solucionar una petición pendiente SOLO para pedidos, dos de los cuales no completan nada.... Aunque de hecho (no de forma) la solución de la solicitud de orden pendiente es bastante fácil.
Lo de "imposible" es un poco precipitado.
Exactamente, es imposible. Diferentes objetos-consulta - diferentes propiedades. No se puede poner todas las propiedades en un objeto de consulta.
Sólo me pregunto cómo una tarea simple puede ser resuelta durante un mes y medio en tres artículos. Si este método de programación se considera "eficiente", entonces me alegro de programar de otra manera.
Es imposible rastrear todas las llamadas de EA al servidor.
Lo pregunto, porque la solución al problema del envío repetido de órdenes fallidas (obviamente) no requiere complicación y se resuelve de forma sencilla.
Si las órdenes no se envían utilizando métodos de la biblioteca, entonces toda la lógica de negociación debe ser escrita de forma independiente. La biblioteca proporciona una oportunidad para no hacer esto, pero no le obliga a hacer todo a través de su funcionalidad.
En tal situación, la biblioteca no puede gestionar funciones de negociación que no sean propias. Pero será capaz de informar del hecho de una solicitud de comercio exitosa enviada a través de funciones de terceros.
Utilice la funcionalidad de la biblioteca, donde hay una reacción a los errores devueltos por el servidor y su procesamiento adecuado.
¿Qué ve como un manejador de códigos de retorno del servidor?
Exacto, es imposible. Diferentes objetos de consulta - diferentes propiedades. No se puede insertar todas las propiedades en un objeto de consulta.
Sólo me pregunto cómo una tarea tan simple se puede resolver en tres artículos durante un mes y medio. Si este método de programación se considera "eficiente", entonces me alegro de programar de otra manera.
Los objetos son solicitudes comerciales pendientes. Toda la información sobre cualquier solicitud de comercio se almacena en una sola estructura para todas las solicitudes - MqlTradeRequest.
¿Me estás tomando el pelo?
De hecho, describo el concepto. Paso a paso. En artículos (yo mismo escribo los textos, compruebo si hay errores tres o cuatro veces, y se me escapan algunos). Expongo el contenido del concepto en artículos, la lógica y la funcionalidad, muestro cómo hacerlo. Al mismo tiempo, pienso de antemano varias opciones, y gran parte de ellas se tiran a la papelera; es decir, de hecho, escribo código tres o cuatro veces más de lo que hay en los artículos. A veces reescribo completamente todo el código desde cero, y según principios diferentes. Luego pruebo todo en el tester y demo - lo que se describe en cada artículo. Y luego me pierdo algunos errores y corregirlos más tarde en los próximos artículos.
Si el código funciona desde la primera vez - significa que hay una bomba enterrada en ella, y esperar una gran sorpresa en el futuro.
Me sorprende que escribas todo por ti mismo en una hora. Sin comprobaciones, sin pruebas, y con tal de que se mueva :)
Realmente quiero entender lo que consideras simple aquí. ¿Por qué no quieres entender que esto es una parte de la funcionalidad futura de otras partes de la biblioteca, y todo por adelantado debe estar vinculado "en tu mente" con lo que aún no está allí, pero está previsto?
No me pongo una tarea para hacerlo una vez y dejarlo flotar. Tengo otra tarea: pensar cómo se interconectará todo más adelante. Lleva tiempo y un cierto enfoque. Si te resulta difícil, bueno... Entonces es complicado.
...
Y lo que se ve como el controlador de código de retorno del servidor?
Le mostraré una solución corta y eficaz.
1. Declarar una variable global: cadena Del_req;
2. Escribe la función void Delayed_request(). La función será llamada desde OnTimer() una vez por segundo (si Del_req != NULL).
3. Añada el parámetro int delayed_request_ID = 0 a cada función de negociación que envíe una orden.
4. Cada solicitud de operación devuelve una respuesta del servidor. Si delayed_request = 0 (no es una llamada repetida de Delayed_request() ) y la respuesta del servidor requiere repetir la petición, las funciones de comercio escriben todos los parámetros de la llamada en la variable Del_req (a través de dos separadores - delayed_request_ID y parameters) y al final de la línea añaden el número de intentos requeridos (por ejemplo, 10).
5. La función Delayed_request() comprueba la cadena Del_req una vez por segundo. Si la cadena no es NULL, la función la pone en un array y la recorre para encontrar la subcadena de la llamada, la encuentra, la extrae de la cadena total, la divide, mira el tipo de llamada y pasa los parámetros a la función de comercio requerida junto con el delayed_request_ID. A continuación, mira el contador de llamadas y lo resta en uno. Si el contador es cero después de restar uno, borra toda la subcadena de llamada de la cadena Del_req total.
6. Si la función de comercio acepta una llamada con delayed_request_ID y la petición al servidor ha tenido éxito, borra la subcadena de llamada de la cadena Del_req común (la encuentra por delayed_request_ID).
Todo esto se puede hacer en un día y se puede aplicar no sólo a las solicitudes de comercio, sino a cualquier solicitud.
ZY. No trolling, estoy realmente sorprendido por la no obviedad de soluciones simples para los programadores maduros.
Le mostraré una solución breve y eficaz.
1. Declarar una variable global: cadena Del_req;
2. Escribe la función void Delayed_request(). La función será llamada desde OnTimer() una vez por segundo.
3. Añada un parámetro int delayed_request_ID = 0 a cada función de negociación que envíe una orden.
4. Cada solicitud de operación devuelve una respuesta del servidor. Si delayed_request = 0 (no es una llamada repetida de Delayed_request() ) y la respuesta del servidor requiere repetir la petición, las funciones de comercio escriben todos los parámetros de la llamada en la variable Del_req (a través de dos delimitadores - delayed_request_ID y parameters) y al final de la línea añade el número de intentos requeridos (por ejemplo, 10).
5. La función Delayed_request() comprueba la cadena Del_req una vez por segundo. Si la cadena no es NULL, la función la pone en un array y hace un bucle para encontrar la llamada, la encuentra, la extrae de la cadena total, la divide, mira el tipo de llamada y pasa los parámetros a la función de comercio requerida junto con el delayed_request_ID. A continuación, mira el contador de llamadas y lo reduce en uno. Si el contador no es cero, Del_req cambia el contador de llamadas en la cadena de llamadas a un valor menor en uno, si es cero, borra toda la cadena de llamadas de la cadena total Del_req.
6. Si la función de comercio recibe una llamada con delayed_request_ID y la petición al servidor ha tenido éxito, borra la subcadena de llamada de la cadena Del_req total (la encuentra por delayed_request_ID).
Todo esto se puede hacer en un día y se puede aplicar no sólo a las solicitudes de comercio, sino a cualquier solicitud.
ZY. No trolling, estoy realmente sorprendido por la no obviedad de soluciones simples para los programadores maduros.
¿Frenar deliberadamente los métodos?
¿Y cuál es la diferencia entre el método propuesto y el que se está haciendo? ¿Aparte del hecho de que habrá que pasar por costosas funciones de trabajo con cadenas? Conceptualmente nada. Por eso - será como se pretende. Además, lo que se está haciendo, y aún no lo sabes, servirá para ampliar la funcionalidad de trabajar con consultas diferidas.
¿Presionando conscientemente los frenos en los métodos?
¿Y cuál es la diferencia entre el método propuesto y el que se está haciendo? ¿Aparte del hecho de que habrá que pasar por costosas funciones de trabajo con cadenas? Nada. Por eso - será como se pretende. Además, lo que se está haciendo, y aún no lo sabes, servirá para ampliar la funcionalidad de trabajar con consultas diferidas.
Haz lo que consideres oportuno. Es tu creatividad. Yo he expresado mi opinión.
Y no hay frenos. Las peticiones pendientes se siguen enviando una vez por segundo.
La diferencia es que las solicitudes pendientes no se convierten en Objetos en toda regla y, por tanto, no arrastran mucho código detrás.
Haz lo que creas conveniente. Es tu arte. Yo di mi opinión.
Y no hay frenos. Las solicitudes pendientes se envían una vez por segundo de todos modos.
¿Por qué se envían una vez por segundo? ¿Para inundar el servidor comercial?
Se diferencia por el hecho de que las consultas pendientes no se convierten en Objetos completos y, por tanto, no arrastran mucho código detrás.
Y necesito objetos completos para implementar lo que he planeado más adelante. Pero tú aún no lo sabes, y estás intentando ofrecer formas ineficaces de resolver una pequeña parte de la tarea para seguir trabajando. Y aquí todo está vinculado, y el concepto general es el mismo - las otras cosas planeadas en el futuro dependen de esta pequeña parte.
De todos modos, gracias por tu opinión - cualquier opinión es útil y tiene sentido.
ZY. Y, sí - no es terrible escribir una pieza de código que funcione, extensible y compatible en lugar de reescribir constantemente soluciones incompletas escritas previamente sin pensar para las siguientes tareas.