Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Então, você quer que eu continue a desperdiçar as vantagens do OOP, e todos continuam a me perseguir?) Mas, em essência, você está certo. A discussão foi na direção errada.
Mas eu não estou correndo. Apenas não responda aos trolls.
No TWS, as barras são formadas pelo tempo, independentemente da chegada de uma cotação. Se não houver cotação e for hora de uma nova barra, a barra aparece como um traço no preço da última cotação. Neste caso, todos os indicadores são desenhados da mesma forma que na MT. Todas as minhas idéias sobre bares vêm da experiência de trabalhar com TS.
Se fosse o mesmo na MT, minha solução seria a mais eficaz. No entanto, não é...
Portanto, não vou mais sugeri-lo para uso.
Peter, sugiro outro tópico para discussão, pela segunda vez. Não há necessidade de escrever nada, apenas teoria.
Mas eu não estou correndo. Os rolos simplesmente não respondem.
Entendo. Portanto, o bar pode não chegar quando o iBars é solicitado, mas pode chegar um momento após o pedido. Então, o sistema não o detectará. Essa é a questão.
E depois, para ser acessado continuamente? - Claramente não é a melhor solução.
Mas se alguém precisa conseguir uma nova barra o mais rápido possível sem pesquisar no OnTimer, há interrupções personalizadas.
Se você apenas repensar o conceito do bar aqui, tudo se encaixará no lugar. Os recursos seriam economizados e a solução seria simples. Na minha opinião, a barra deveria estar ligada ao tempo, não a citações.
Portanto, não há erro em meu código. Há uma diferença no conceito de barras entre plataformas.
E não há nada a discutir aqui.Polimorfismo em sua forma pura. Regras do OOP.
Não há nada a discutir para aqueles que estão por dentro. Aqui está um exemplo de como cheguei à decisão de aprender pelo menos um pouco sobre o OOP.
Não foi por nada que assumi a função de definir uma nova barra como exemplo. Foi com esta função que tudo começou. A função que define uma nova barra na atual TF foi escrita há muito tempo. De repente, eu também precisava dele, mas detectando-o em uma certa TF. Bem, sem problemas. Eu o reescrevi em meio clique. Mas, de repente, eu preciso dele apenas para a atual TF. Por que eu deveria passar PERIOD_CURRENT a esta função? Não há problema, eu a reescrevi novamente e agora eu tenho duas funções com nomes diferentes.
Não sei quantas vezes tenho que reescrevê-la ou lembrar qual delas devo chamar. E quando entendi que eu poderia ter várias funções com um nome e parâmetros de entrada diferentes, minha agonia acabou...
Acontece que não há erro em meu código. Há uma diferença no conceito de barras entre as plataformas.
A propósito, se na minha solução apenas mudar a freqüência de preenchimento da matriz e em vez de pausar um minuto, o acesso uma vez por segundo, o problema poderia ser completamente resolvido. Neste caso, é pouco provável que a carga sobre o sistema aumente. Você pode verificá-lo.
Substituir if(Minuto*Timer_frequency >= 60000) por if(Minuto*Timer_frequency >= 1000).
Desculpe, Pyotr, mas seu código é apenas o caos.