Mt4 Fim do apoio. - página 40

 
Реter Konow:
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.

 
Alexey Viktorov:

Peter, sugiro outro tópico para discussão, pela segunda vez. Não há necessidade de escrever nada, apenas teoria.


O que há para discutir aqui. Opolimorfismo em sua forma mais pura. Regras do OOP.
 
Alexey Viktorov:

Mas eu não estou correndo. Os rolos simplesmente não respondem.

Voltarei ao seu tópico mais tarde.
 
Реter Konow:

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.

Foi apenas uma tarefa fraca. Mas se alguém precisar dele - para receber uma nova barra de outro símbolo o mais rápido possível, sem pesquisa contínua no Timer, há também interrupções do usuário.
 
Nikolai Semko:
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.

 
Nikolai Semko:
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...

 
Реter Konow:


Acontece que não há erro em meu código. Há uma diferença no conceito de barras entre as plataformas.

Desculpe, Peter, mas seu código é apenas o caos.
 
Nikolai Semko:

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).

 
Nikolai Semko:
Desculpe, Pyotr, mas seu código é apenas o caos.
Sinto muito Nikolai, mas estas são palavras vazias. É um pouco incomum ouvir isso de um programador.
Razão: