Fazendo um projeto de crowdsourced em Tela - página 34
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
A aplicação é separada, a GUI é separada.
Mas o processamento de dados deduzidos na GUI é realizado de forma síncrona de qualquer forma.
Por exemplo, a aplicação envia 10000 elementos para a GUI e a GUI processa todos esses elementos sequencialmente.
Este é o problema. É necessário paralelizar o processamento dos elementos recebidos e sua saída na GUI. Base, texto, ícone.
Mais ainda, há três ciclos por célula.
É isso mesmo. Mas, nas circunstâncias atuais, o processamento em paralelo é inconveniente. Precisamos conectar mais EAs ou serviços. Será uma implementação incômoda e desconectada.
Há uma maneira baseada em cartas-objeto. Ainda não entrei no assunto, mas isso pode me ajudar a criar vários fios. Tem algo a ver com os modelos...
Entendo o ponto, a aplicação é separada, a GUI é separada.
Mas o processamento dos dados de saída na GUI é realizado de forma síncrona de qualquer forma.
Assim, por exemplo, a aplicação envia 10000 elementos à GUI e a GUI processa todos esses elementos sequencialmente.
Este é o problema. É necessário paralelizar o processamento dos elementos recebidos e sua saída na GUI. Base, texto, ícone.
Mais ainda, pois há três ciclos por célula.
É pouco provável que isto funcione. Mesmo a winda processa a interface em um único fio. Caso contrário, as janelas e controles não serão priorizados. Somente a GUI em si e o processamento dos vários dados podem ser divididos em fios. De fato, mesmo a mudança de dados nos controles não é permitida a partir de outro fio. Um diálogo deve ser sempre coerente para que qualquer renderização e reação de qualquer diálogo seja estritamente em uma única linha, ou seja, tudo acontece de forma síncrona.
Todas as operações na MT são estritamente sincronizadas e isto não pode ser realmente alterado a menos que os desenvolvedores adicionem fios à aplicação.
É bastante surpreendente que os desenvolvedores estejam tentando expandir a funcionalidade MT em termos de trabalho com bancos de dados, com python, com sharpe... mas eles se oferecem para fazer tudo na mesma linha...
É simplesmente incrível.
Concordo com a surpresa.
A única saída é serrar uma dll com funções assíncronas para suas aplicações.
Mas tais aplicações não podem sequer ser colocadas na kodobase, porque a dll não é permitida.
É pouco provável que isto funcione. Até mesmo a interface Windows é tratada em uma única linha. Caso contrário, as janelas e controles não serão priorizados. Somente a GUI em si e o processamento dos vários dados podem ser divididos em fios. De fato, mesmo a mudança de dados nos controles não é permitida a partir de uma linha diferente. Um diálogo deve ser sempre coerente, de modo que qualquer renderização e reação de qualquer diálogo está estritamente em uma única linha, ou seja, tudo acontece de forma síncrona.
Parece-me que tudo vai dar certo, é apenas necessário pensar com antecedência sobre a prioridade do processamento assíncrono de dados.
Ou seja, construir um esquema de processamento assíncrono, com processamento síncrono.
Concordo, com surpresa.
A única saída é serrar uma dll com funções assíncronas para suas aplicações.
Mas tais aplicações não podem sequer ser colocadas em uma kodobase porque a dll não é permitida.
Na verdade, ainda não há necessidade real de paralisar o processamento de eventos GUI. Se as tabelas de 1000 células funcionam relativamente rápido mesmo em MT4, há velocidade mais do que suficiente para o resto dos eventos. Em minha prática não há desaceleração. Se você precisar de animação super-rápida, você pode conectar o OpenCL. O MT5 puxa perfeitamente a GUI regular. Sem nenhum problema. Acabo de mostrar que é preciso estar muito atento no que diz respeito ao redesenho de telas.
Se o próprio Expert Advisor incluir cálculos pesados, a freqüência de saída de dados na GUI pode ser reduzida. O redesenho de uma grande janela pode chegar a 100 ms, mas geralmente é muito menos. Portanto, um atraso de 100ms na GUI só pode ser notado com cálculos MUITO pesados de EA.
Concordo, com surpresa.
A única saída é escrever uma dll com funções assíncronas para suas aplicações.
Mas tais aplicações não podem sequer ser colocadas em uma kodobase porque a dll é proibida.
Muitas coisas podem ser feitas a nível de DLL.
Isso é tudo para o qual a MT não foi projetada e pode+must+do lá :-)
Você não pode controlar a dll, por isso não está no mercado. A propósito, você pode encontrar dlls em kodobase. Talvez eles a tenham proibido agora por alguma razão.
PS, a propósito, pergunta curiosa - a DLL pode ser assinada com a chave do desenvolvedor. É possível permitir tal DLL no mercado e kodobeise também, mas ela será vinculada à infra-estrutura da Microsoft. Alguém aqui pronto para comprar tal licença para a Visual C?Concordo, com surpresa.
A única saída é serrar uma dll com funções assíncronas para suas aplicações.
Mas tais aplicações não podem sequer ser colocadas no kodobase porque a dll é proibida.
Sim, esse é o problema principal! O mesmo mercado proíbe o uso de dlls, portanto, temos que reinventar a roda. Ok, se alguém pensa que a GUI não é necessária, mas qualquer cálculo longo e complexo em qualquer caso em um só fio não funcionará, tudo ficará pendurado! Portanto, tem que ser feito em um dll... o que é proibido no mercado...
E assim por diante. Por esta razão, tenho que desenhar e resolver tudo com métodos mql.
Na verdade, a separação da GUI e da lógica em fios já é, naturalmente, possível. Aqui os caras já discutiram a questão do paralelismo https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
Como resultado, a forma em si poderia ser deixada no fio principal, como é feito em winnda, enquanto quaisquer cálculos adicionais poderiam ser movidos para a execução "de fundo". É assim que as janelas e o linux e o andróide funcionam.
Você pode fazer tantas coisas em nível de DLL.
É para isto que a MT não serve e pode+must+do :-)
Você não pode controlar a dll, por isso não está no mercado. A propósito, temos dlls em kodobase. Talvez o tenham proibido agora por causa de algum alvoroço.
PS, a propósito, pergunta curiosa - a DLL pode ser assinada com a chave do desenvolvedor. É possível permitir tais DLLs no mercado e kodobeise também, mas será vinculado à infra-estrutura da Microsoft. Alguém aqui pronto para comprar tal licença para a Visual C?Sim, você não pode controlar a dll, mas poderia permitir as mesmas bibliotecas de vento...
Não vá tão longe: mesmo como parte de uma biblioteca padrão, há funções para acessar winAPI! Mas qual é o objetivo? Afinal, você não pode colocá-lo no mercado....
Certo, com toda essa conversa, entramos em outra enchente.
Há muitas coisas que você pode fazer em nível de DLL.
Isto é o que a MT não se destina e pode+must+ser feito lá :-)
Você não pode controlar a dll, por isso não está no mercado. A propósito, você pode obter dlls em kodobase. Talvez o tenham proibido por alguma razão.
PS, a propósito, pergunta curiosa - a DLL pode ser assinada com a chave do desenvolvedor. É possível permitir tais DLLs no mercado e kodobeise também, mas será vinculada à infra-estrutura da Microsoft. Alguém aqui pronto para comprar tal licença para a Visual C?Por que você deve se ligar à infraestrutura da Microsoft?
Acho que qualquer chave pode ser usada para assinar um dll, desde que seja controlada pela MQ.
Segue-se que estas chaves devem ser emitidas pela MQ, e controlar a quantidade de hash da aplicação.
Por que eles deveriam se prender à infra-estrutura da Microsoft?
Eu acho que qualquer chave pode ser usada para assinar um dll, desde que seja controlada pela MQ.
Segue-se que estas chaves devem ser emitidas pela MQ, e controlar a soma do hash do pedido.
mas porque a microsoft é a chefe neste formigueiro :-)
Por que você acha que as pessoas perdem seus dados de login ao atualizar e ativar produtos sobre o vinhedo pirateado?