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
Así que, ¿quieres que siga destrozando las ventajas de la OOP, y que todo el mundo me siga trolleando)? Pero en esencia tienes razón. La discusión ha ido en la dirección equivocada.
Pero no estoy troleando. No respondas a los trolls.
En la TWS, las barras se forman por tiempo, independientemente de la llegada de una cotización. Si no hay ninguna cotización y es el momento de una nueva barra, ésta aparece como un guión sobre el precio de la última cotización. En este caso, todos los indicadores se dibujan de la misma manera que en MT. Todas mis ideas sobre los bares provienen de la experiencia de trabajar con TS.
Si fuera igual en MT, mi solución sería la más eficaz. Sin embargo, no es...
Por lo tanto, no voy a sugerir más su uso.
Peter, sugiero otro tema de discusión, por segunda vez. No es necesario escribir nada, sólo la teoría.
Pero no estoy troleando. Los trolls simplemente no responden.
Ya veo. Así que la barra puede no llegar cuando se solicitan las iBars, pero puede llegar un momento después de la solicitud. Entonces, el sistema lo echará de menos. Esa es la cuestión.
Entonces qué, ¿acceder continuamente? - Está claro que no es la mejor solución.
Pero si alguien necesita obtener una nueva barra lo más rápido posible sin sondear el OnTimer, hay interrupciones personalizadas.
Si se replantea el concepto del bar aquí, todo encajará. Se ahorrarían recursos y la solución sería sencilla. En mi opinión, la barra debería estar vinculada al tiempo, no a las cotizaciones.
Así que no hay ningún error en mi código. Hay una diferencia en el concepto de barras entre las plataformas.
Y no hay nada que discutir aquí.El polimorfismo en estado puro. Reglas OOP.
No hay nada que discutir para los que están al tanto. He aquí un ejemplo de cómo llegué a la decisión de aprender al menos un poco de POO.
No en vano he tomado como ejemplo la función de definir una nueva barra. Con esta función comenzó todo. La función que define una nueva barra en la TF actual fue escrita hace mucho tiempo. De repente yo también lo necesitaba, pero detectándolo en una determinada TF. Bueno, no hay problema. Lo reescribí en medio clic. Pero de repente lo necesito sólo para el TF actual. ¿Por qué debo pasar PERIOD_CURRENT a esta función? No hay problema, lo he vuelto a escribir y ahora tengo dos funciones con nombres diferentes.
No sé cuántas veces tengo que reescribirlo o recordar a cuál debo llamar. Y cuando comprendí que podía tener varias funciones con un mismo nombre y diferentes parámetros de entrada, se acabó mi agonía...
Resulta que no hay ningún error en mi código. Hay una diferencia en el concepto de barras entre las plataformas.
Por cierto, si en mi solución solo se cambiara la frecuencia de llenado del array y en vez de hacer una pausa al minuto, se accediera una vez por segundo, el problema podría quedar completamente resuelto. En este caso, es poco probable que la carga del sistema aumente. Puede comprobarlo.
Sustituir if(Minuto*Frecuencia_del_temporizador >= 60000) por if(Minuto*Frecuencia_del_temporizador >= 1000).
Lo siento, Pyotr, pero tu código es un caos.