Minha abordagem. O núcleo é o motor. - página 146
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
Реter Konow:
...
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 e isso é uma carga pesada sobre a 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.
No MT5, os gráficos podem ser destacados. E então você tem que voltar a pensar no conceito.
Cada EA tem sua própria cópia do kernel do parâmetro. Ele pode ser desligado temporariamente da GUI comum e outro EA pode ser conectado ao motor. É importante que eles sejam cópias da mesma EA.
Entretanto, existem algumas dificuldades, que eu mesmo ainda não compreendi 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.
Deixe as cópias do EA dizerem ao motor seu endereço com freqüência. Um fio curto. O motor reagirá e "falará" com a cópia que tem o mesmo endereço que seu atual. O intercâmbio padrão será realizado. Se o endereço mudar no motor, ele começa a "trocar" com a cópia que define o endereço correspondente. A troca padrão para "éter" acrescenta conselheiros ou indicadores para expor seu breve endereço. Vários bytes. E a função "ouvir os endereços do motor inicia quando o usuário pressiona o botão "reconfigurar" na GUI do motor. Talvez seja algo parecido com isto.
No MT5 você pode destacar os gráficos. E então você tem que voltar a pensar no conceito.
Eu simplesmente não estou ciente disso. A carta é destacada puramente "territorialmente", ela se torna livre das coordenadas da janela principal do terminal? Nos fluxos de troca, ele ainda está totalmente conectado ao terminal?
Eu simplesmente não estou ciente disso. A carta é destacada puramente "territorialmente", ela se torna livre das coordenadas da janela principal do terminal? E nos fluxos de troca com o terminal, ele ainda está conectado ao terminal na sua totalidade?
O gráfico é destacado, mas não muda a essência. (Eles estão fazendo uma bagunça por nada). Não faz sentido fazer cópias da GUI para cada cópia da EA. Não que eu consiga ver, pelo menos. Mas seria ótimo mover uma GUI entre os gráficos de cópias.
Se houver um gráfico do centro de controle de cópia EA com o motor e a GUI principal localizados nele, seria útil.
A GUI da EA deve ser feita com a expectativa de que a EA tenha muitas cópias colocadas em diferentes instrumentos.
SZY. A tabela permanece na mesma janela, somente a própria janela pode ser "tirada", do terminal.
Deixe as cópias dos conselheiros dizerem ao motor seu endereço com freqüência. Um fio curto. O motor reagirá e "falará" com a cópia que tem o mesmo endereço que seu atual. O intercâmbio padrão será realizado. Se o endereço mudar no motor, ele começa a "trocar" com a cópia que define o endereço correspondente. A troca padrão para "éter" acrescenta conselheiros ou indicadores para expor seu breve endereço. Vários bytes. E a função "ouvir os endereços do motor inicia quando o usuário pressiona o botão "reconfigurar" na GUI do motor. Talvez seja algo parecido com isto.
Você vê a essência corretamente. Apenas os detalhes não são exatos.
Trocar a "comunicação" em si, não é um problema. Mas, ao trocar, você tem que reinicializar toda a GUI. Afinal de contas, em janelas e elementos de diferentes cópias, valores diferentes. Portanto, é necessário redesenhar quase tudo.
Os valores dos parâmetros de cada cópia são armazenados no Kernel de parâmetros. Isto é um conjunto. Enquanto a cópia estiver desconectada do motor, as mudanças de valores só ocorrerão na cópia do kernel do parâmetro do Expert Advisor. Assim que o motor é conectado, tudo deve ser transferido deste núcleo para ele. Sincronizar cópias do Kernel do Parâmetro no Motor e o Expert Advisor conectado. Portanto, você precisa transferir uma grande quantidade de informações (Parameter Core), e redesenhar as janelas. Depois disso, será possível ajustar o Expert Advisor conectado e outros entrarão em modo independente. Então, a conexão será feita com eles e a mesma coisa acontecerá.
Será assim. No entanto, há muitas nuances técnicas.
Peter. Com um período de N ms o EA recebe algo do motor, e depois disso passa seu preparado algo para o motor. O conselheiro então espera a chegada do tick ou um novo lote de intercâmbio de interrogatório. Certo?
Quase certo. Comunicação e espera que o tique, ou outros eventos, aconteçam de forma assíncrona.
O cronograma é desvinculado, mas não muda o ponto. É uma perda de tempo).
...
SZY. A tabela permanece na mesma janela, somente a própria janela pode ser "tirada", do Terminal.
E de acordo com sua concepção de que somente um gráfico atual é visível de cada vez, e somente ele pode ser atualizado, será quebrado - haverá tantos gráficos visíveis quanto se destacam.
Certamente não é um pesadelo, mas também não é bom - apenas um dos gráficos visíveis "viverá", e o resto?
Você acha que isto é normal? Bem, se assim for, mais uma vez estou convencido da falta de seriedade na solução de bugs - se existe um, não é para consertá-lo, mas para escondê-lo.
Quase certo. A comunicação e a espera de um tique, ou outros eventos, acontece de forma assíncrona.
Que tal isso? Os consultores, cada um com alguns (OnTimer) frequentes, enviam ao motor sua seqüência de códigos. Todas as linhas de código são diferentes. O motor analisa internamente os fios de entrada e "reconhece" um, por exemplo, do Expert Advisor número 3. Em resposta a esta EA, ela envia um "sinal" para iniciar a transmissão principal. O motor trabalha com este Expert Advisor.
Se uma pessoa apertar o botão Switch, o motor analisará os Conselheiros permitidos, e eles serão indexados, sob números. Diz à EA atual para mudar para o estado de definição de um endereço, como se o desligasse do fluxo de trabalho, seleciona uma cadeia de código com o índice por mais 1 e aguarda a chegada da mesma cadeia de código de qualquer outra EA. Quando o endereço coincide, ele envia um sinal a este Expert Advisor para parar de expor o endereço e iniciar a troca. O único Expert Advisor e série de cópias, que não está no modo de faturamento, receberá a troca. Em resumo, algo como.
Se o motor receber um endereço, ele faz um intervalo de tempo para proibir o recebimento de endereços. Para que os endereços não se sobreponham.
Que tal isso? Os Conselheiros Especialistas, cada um com uma freqüência de algum tipo (OnTimer), envia para o motor sua própria seqüência de códigos. Todas as linhas de código são diferentes. O motor analisa internamente os fios de entrada e "reconhece" um, por exemplo, do Expert Advisor número 3. Em resposta a esta EA, ela envia um "sinal" para iniciar a transmissão principal. O motor trabalha com este Expert Advisor.
Se uma pessoa apertar o botão Switch, o motor analisará os Conselheiros permitidos, e eles serão indexados, sob números. Diz à EA atual para mudar para o estado de definição de um endereço, como se o desligasse do fluxo de trabalho, seleciona uma cadeia de código com o índice por mais 1 e aguarda a chegada da mesma cadeia de código de qualquer outra EA. Quando o endereço coincide, ele envia um sinal para o Expert Advisor para parar de expor o endereço e iniciar a troca. O único Expert Advisor e série de cópias, que não está no modo de faturamento, receberá a troca. Em resumo, algo como.
Se o motor receber um endereço, o tempo de inibição do endereço será expirado. Para que os endereços não se sobreponham.
Esta não é a abordagem correta. Deixe-me explicar:
Cada cópia da EA não pára de escrever suas mensagens para o motor em seu próprio recurso separado. Ao mesmo tempo, cada cópia da EA inicializa os valores de seus próprios elementos em sua cópia dos parâmetros do kernel. Ou seja, mesmo quando desligado do motor, todas as cópias do EA devem funcionar corretamente.
Quando o motor muda as conexões entre as cópias do EA, ele deve sincronizar seus parâmetros do kernel com o kernel do EA conectado. Depois disso, redesenhar os elementos nas janelas, de modo que eles exibam as informações reais.
Quanto à comunicação com o Expert Advisor selecionado, tudo é simples. O recurso para receber mensagens do motor (assim como o recurso de mensagens para o motor), cada EA terá seu próprio recurso. Ou seja, o motor simplesmente registrará suas mensagens no outro recurso, e lerá mensagens do outro recurso. O recurso que pertence à EA conectada.