Minha abordagem. O núcleo é o motor. - página 145
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
Presumo que cada fluxo de e para o motor deve ter algum tipo de traço de fluxo, uma espécie de número mágico, e um traço de fluxo que funcione com o testador (é invariavelmente único). O motor reage ao fluxo atualmente ajustado e os Conselheiros Especialistas, indicadores reagem a seu atributo (número pseudo-magnético) do infostream.
Tudo funciona bem no testador agora, estou controlando o Expert Advisor no testador a partir de outra janela. Está no modo simulador.
Atualmente, as mensagens entre a EA e o motor não estão vinculadas a um determinado feitiço ou nome da EA. Isso significa que se o motor escrever informações em um recurso, elas serão lidas por qualquer consultor especializado que tenha sido criado para comunicação. A fim de separar os fluxos de comunicação, cada EA deve definir um rótulo especial no cabeçalho da mensagem. E então, ou ler e seguir as instruções ou ignorá-las. Deve haver um rótulo separado para Consultores Especialistas no testador.
Mas aqui vemos a necessidade de uma GUI universal para o motor através da qual possamos configurar e mudar as comunicações. Também para receber informações sobre os Conselheiros Especialistas.
Portanto, temos que mudar o conceito de EAs. Para ser mais preciso, temos que atualizá-lo.
Aqui está o problema.
Temos que ter uma GUI personalizada para cada EA ou uma GUI comum para todas elas. Se for comum, então deve ser invariante. Tem que ser bem pensado com antecedência. Cada consultor especializado (mesmo sem a GUI), deve ter alavancas internas que ele fornecerá ao motor.
Algo em que pensar...
Mas aqui chegamos à necessidade de uma GUI universal para o motor, através da qual se possa configurar e mudar a comunicação. Também, para receber informações sobre EAs.
Basta que haja uma parte administrativa necessária e suficiente permanentemente projetada e configurada no motor, que trata da administração do controle e da mais variada parte personalizada, construída de acordo com o projeto do cliente.
Basta que haja uma parte administrativa necessária e suficiente permanentemente projetada e configurada no motor, que trata da administração da gestão e uma grande variedade de peças personalizadas, construídas de acordo com o projeto do cliente.
Esta parte administrativa não é compreensível. O que é suposto ser?
Se o motor funciona com um Expert Advisor, isso é uma coisa. E se funciona com vários outros diferentes, isso é outra coisa.
Ainda falta uma estrutura conceitual...
Esta é a parte administrativa que não está clara. O que deveria ser?
Se o motor funciona com um EA, isso é uma coisa. Se funciona com vários outros diferentes, esse é outro.
Até agora, há uma falta de estrutura conceitual...
Digamos algo como isto.
E no EA ou indicador nas configurações iniciais, o mesmo campo "Objeto 1", etc.
Digamos algo como isto.
E no EA ou indicador nas configurações iniciais, o mesmo campo "Objeto 1" etc.
Eu me pergunto. Você quer dizer que devemos mudar a conexão com estes botões? Mas, neste caso, todos os Expert Advisors devem ser cópias de um EA rodando em pares diferentes.
E se os Conselheiros Especialistas forem diferentes?
Digamos algo como isto.
E no EA ou indicador nas configurações iniciais o mesmo campo "Objeto 1", etc.
Vou implementá-lo primeiro. Com um EA em pares diferentes. E então eu vou descobrir como lidar com diferentes EAs.
A propósito, aqui está uma boa demonstração de trabalho com o construtor. Dinâmico, sem palavras, e à música. :)
CRIANDO ESTÚDIO VISUAL
https://www.mql5.com/ru/blogs/post/712102
A propósito, aqui está uma boa demonstração de trabalho com o construtor. Dinâmico, sem palavras, e à música. :)
ESTÚDIO VISUAL
Original.
Digamos algo como isto.
E no EA ou indicador nas configurações iniciais o mesmo campo "Objeto 1", etc.
Estes são marcados como conectados ao controle. E há apenas um objeto que é controlado. Portanto, há um interruptor de comutação em algum lugar com uma grande indicação.
Estes são marcados como conectados ao controle. Mas há um controle que é especificamente controlado. Portanto, há um interruptor de comutação em algum lugar com uma grande indicação.
Cada EA tem sua própria cópia do kernel do parâmetro. Pode ser temporariamente desconectado da GUI comum e conectado ao motor por outro EA. É importante que eles sejam cópias da mesma EA.
No entanto, existem algumas dificuldades aqui que eu mesmo não compreendo totalmente.
Em teoria, a pergunta soa assim:
Por que precisamos adicionar um motor com GUI para cada gráfico de uma cópia do EA se podemos fazer um motor com a GUI comum e conectá-lo a todas as cópias do EA?
Na prática, vamos encontrar algumas dificuldades técnicas.
A cópia do Expert Advisor pode escrever novos valores em sua cópia do kernel do parâmetro. Se uma das cópias não se conectar ao motor, o núcleo só mudará na lateral da cópia. Assim, ao reconectar, temos que passar todo o núcleo para o motor e o motor redesenhará todos os elementos em todas as janelas onde for necessário. Isto é possível, em princípio.
Ou refazer o próprio kernel do parâmetro, tornando-o um recurso. Nesse caso, o motor receberá todas as mudanças de uma só vez e apenas redesenhará os elementos. Isto não é uma má idéia.
Mas, o que isso nos dá?
Talvez reduzamos a carga da CPU, liberando as roscas. Se tivermos 10 cópias de EA rodando em 10 pares e carregarmos cada motor com GUI, a carga total da CPU pode ser muito grande. Porque cada GUI requer o redesenho de elementos que é uma carga pesada na CPU. Mas na verdade, podemos ver apenas uma GUI concreta de uma cópia. Os outros estão escondidos.
Portanto, é provavelmente o caminho certo a ser seguido. Fazer um motor comum.