¿Es posible cerrar varias órdenes al mismo tiempo? - 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
el teléfono y el portátil son obviamente las soluciones correctas. ni siquiera se discute. me preguntaba si alguien había intentado hacer algo.... pero no es el caso.
Al acceder a la página, aparecerá el estado de la cuenta (saldo, beneficio...) y la lista de órdenes abiertas (símbolo del ticket lote stop take profit). + campo de texto y botón de envío. sobre el campo un pequeño tooltip:
y en la opción 6, puede establecer una lista de números (6 1234 65433 2345).
Y entonces, incluso desde un teléfono móvil o desde el Inetcafe o salón de juegos más cercano, se puede hacer al menos algo incluso con estos 7 puntos. pero no lo harán..... no en 4 o 5 :(((
Y a la derecha. Es muy fácil en la API del servidor de una meta. Pero las empresas de corretaje suelen tomarse demasiadas molestias: el trato telefónico, como en los buenos años 90 :)
En cuanto al cierre de órdenes por lotes. Por razones obvias, esta función simplemente no puede existir. En primer lugar, es difícil informar acerca de los errores (8 órdenes de 10 se han cerrado, además, con diferentes deslizamientos/desviaciones del precio) y 2 órdenes tienen OFF QUOTES - ¿cómo debemos tratarlas? Además, la cola de solicitudes de un cliente es una, por razones obvias, de nuevo, (por ejemplo, comprobar los requisitos de margen ). Así que en términos de tiempo es equivalente a los cierres de órdenes sucesivas.
El problema está realmente fuera de control. En primer lugar, utilice los ordenadores portátiles (véase más arriba). En segundo lugar, utilice un VPS. En tercer lugar, conéctate a través de tu teléfono (si la línea de tu casa no funciona). Reduzca los problemas al mínimo.
...
El problema está realmente fuera de control. En primer lugar... Reduzca los problemas al mínimo.
Soy consciente de ello ;)
Por ejemplo, el script no puede hacer que el indicador se redibuje, pero puedes enviar un tick al gráfico y el indicador se redibujará. pensé que tal vez hay algo que alguien encontró aquí que está subcomentado
Soy consciente de ello ;)
al principio escribí "seguro que la respuesta es no. pero puede ser...." esperaba un indicador en negrita. por ejemplo, el script no puede hacer que el indicador se redibuje, pero puedes enviar un tick al gráfico y el indicador se redibujará. pensé que tal vez hay algo que alguien encontró aquí que está subcomentado
Bueno, no puede ser sólo allí :) ver sobre la lógica del servidor.
ForexTools:
Pero "simular una interrupción" también lleva tiempo, y aparentemente (por ejemplo, volver a registrarse en la misma cuenta) llevará tanto tiempo como esperar una respuesta normal de cierre de la orden.
Bueno, no puede ser sólo :) ver sobre la lógica del servidor.
Uno quiere lo extraño y mucho. Un programador debe esforzarse por resolver los problemas de forma práctica, incluso con las herramientas ya existentes, en lugar de crear otras nuevas mediante artificios.
Tómalo como una regla.
Probablemente no seas programador :) . A veces quieres estirar tu cerebro con algunas de estas cosas.
No, es que he construido unos super sistemas y que he aprendido la verdad. Hay que ver todo como una aplicación completa, no sólo dentro de un programa concreto. El sistema final implica a todos, desarrolladores, usuarios y mantenedores.
No en vano los desarrolladores de MT se resisten tanto a las innovaciones. Si intentas implementarlo todo, todo empezará a desmoronarse. Tiene que haber un término medio.
¿Por qué? ¿Quién impide que el servidor utilice la "lógica de lotes"? se obtiene una lista de comandos (en una lista / paquete), para cada posición en el paquete, devuelve el código a la matriz.... si quieres ;)
¿Por qué querrías crear entidades innecesariamente...
Lo que realmente podríamos utilizar en MQL es un modelo de hilo de algún tipo. Y la optimización del código. Pero es un caso aparte.
Tal vez alguien se haya enterado, hubo un apagón en San Petersburgo en agosto. Durante dos horas no hubo nada, ni electricidad ni agua, ni emisoras de radio, ni internet, ni televisión, ni teléfonos fijos,
El servicio de telefonía móvil estaba teóricamente disponible, tenían energía de emergencia, pero debido al ligero pánico, todo el mundo llamó a todos. Un SAI en una situación así era inútil, al igual que un teléfono, de hecho. Lo único que se me ocurrió en ese momento fue mantener
otro terminal en el vps, y no sé cómo y si es posible hacer, el software independiente en el vps debe supervisar la presencia de Internet en el equipo principal, y si el "abonado no responde" para ejecutar el script para cerrar todos los puestos.
Pero luego dieron la luz )))
Y en general por la ley de la mezquindad ciertamente se puede perder mucho