Criação de uma GUI para MQLs em modo gráfico. - página 10
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
Sondagens unidirecionais a partir de μl, pips, arquivos ou solicitações na web.
Tenho certeza de que isso seria ótimo! Não estamos falando em enviar nada para a MT. A transferência propriamente dita pode ser feita de qualquer outra forma. O importante é notificar a MT de que alguma ação precisa ser executada. É exatamente o mesmo que na biblioteca GUI que você desenvolveu: todos os colbecs são feitos através de eventos.
A propósito, sobre esta biblioteca: você planeja expandi-la e traduzi-la completamente para a tela? Ou seja, o "produto" final não é um conjunto de objetos gráficos, mas um quadro completo.
E no contexto da revisão da dll, é claro que eu gostaria de poder incluir a dll como recurso na MT, para que eu não tenha que "arrastá-las" junto com o Expert Advisor ou indicador.
Por que parar no dotnet por engano?
A questão não é tanto sobre a GUI. As interfaces podem ser facilmente criadas usando ferramentas MT. É claro, é um pouco complicado e para ampliar as capacidades que preciso para criar minhas próprias classes de processamento, mas tudo pode ser resolvido. Comecei a trabalhar com rede por causa da impossibilidade de implementar alguns algoritmos de trabalho com Internet. É bastante complicado e instável em C++, mesmo na língua nativa, para não mencionar a MT. Uma vez que eu tenha dominado a rede, posso começar a usar a GUI também, porque tudo está pronto para isso, ao contrário do que acontece na MT. Entre as questões abertas de desenvolvimento de aplicações em qualquer idioma, ou seja, em qualquer idioma, já que estas questões não estão ligadas à rede: 1. Feedback, 2. Ligando o GUI ao gráfico (https://www.mql5.com/ru/forum/103764)-um dos tópicos.
Sondagens unidirecionais a partir de µl, pips, arquivos ou consultas na web.
a escolha é sua ;-)
do ponto de vista das aplicações - deve haver uma forma padrão após ligar para a DLL para dizer de volta à MT "isto é o que você queria, isto é o que você obtém".
Cenário típico para cálculos longos, a rede IO - MT chama DLL, DLL cria um fio e algo é feito nela. É preciso haver uma maneira de dizer "é isso, foi calculado". Sem isso, estamos constantemente pesquisando os EAs em busca de algo.
a escolha é sua ;-)
Do ponto de vista das aplicações - deve haver uma maneira padrão de dizer à MT "isto é o que você quer, isto é o que você obtém".
Cenário típico para cálculos longos, a rede IO - MT chama DLL, DLL cria um fio e algo é feito nela. É preciso haver uma maneira de dizer "é isso, foi calculado". Sem ela, estamos constantemente pesquisando a EA para obter algo.
Apoiado por mim!
Bem
Todos nós podemos discutir até o fim sobre os méritos de um ou outro ambiente de desenvolvimento. Mas para quê? Todos nós sabemos que nenhum sistema de desenvolvimento é auto-suficiente, pois resolve problemas específicos. Qualquer outro componente plug-in desenvolvido em qualquer outro idioma ou ambiente pode ser usado para ampliar suas capacidades. Só precisamos facilitar a comunicação. Não vamos longe: as mesmas bibliotecas Windows que usamos através da importação... ...nós os usamos para implementar a funcionalidade que nos falta. E não se pode dizer que é implementado puramente por meio de mql. ))) Então, que diferença faz qual aplicação externa usamos para expandir as capacidades e alcançar os objetivos desejados? Como uma dll autoescrita é pior do que uma dll do Windows?
Aqui está um artigo por exemplo: https://www.mql5.com/ru/articles/364
Mas não se trata de se livrar completamente da dll, simplesmente nunca acontecerá, porque a MT tem estritamente suas próprias tarefas. Neste artigo, as bibliotecas do sistema estão presentes, não importa como você olhe para ele. Sim, ao contrário das bibliotecas caseiras, estas bibliotecas não precisam ser carregadas com o Consultor Especialista ou indicador...
Bem, o que o impede de adicionar a possibilidade de compilar dlls nos recursos da ferramenta?
Sim, você não pode colocá-lo no mercado, porque o mercado não permite o uso de dll, mas seria muito mais conveniente para seu próprio desenvolvimento.
Todos nós podemos discutir até o fim sobre os méritos de um ou outro ambiente de desenvolvimento. Mas para quê? Todos nós sabemos que nenhum sistema de desenvolvimento é auto-suficiente, pois resolve problemas específicos. Qualquer outro componente plug-in desenvolvido em qualquer outro idioma ou ambiente pode ser usado para ampliar suas capacidades. Só precisamos facilitar a comunicação. Não vamos longe: as mesmas bibliotecas Windows que usamos através da importação... ...nós os usamos para implementar a funcionalidade que nos falta. E não se pode dizer que é implementado puramente por meio de mql. ))) Então, que diferença faz qual aplicação externa usamos para expandir as capacidades e alcançar os objetivos desejados? Como uma dll autoescrita é pior do que uma dll do Windows?
Aqui está um artigo por exemplo: https://www.mql5.com/ru/articles/364
Mas não se trata de se livrar completamente da dll, simplesmente nunca acontecerá, porque a MT tem estritamente suas próprias tarefas. As bibliotecas do sistema estão presentes neste artigo, não importa como você olhe para ele. Sim, ao contrário das bibliotecas caseiras, estas bibliotecas não precisam ser carregadas com o Consultor Especialista ou indicador...
Bem, o que o impede de adicionar a possibilidade de compilar dlls nos recursos da ferramenta?
Sim, você não pode colocá-lo no mercado, porque o mercado não permite o uso do dll, mas para seu próprio desenvolvimento seria muito mais conveniente.
Estes pensamentos e cargos têm 10 anos de idade.
Se estamos falando do ecossistema, então devemos simplesmente encerrar o uso de qualquer importação na MT. Mas eles não fazem isso. Afinal de contas, eles não decidiram apenas usar as importações da biblioteca por uma razão. Por um tempo a MT não podia trabalhar com solicitações da web, havia limitações quando se trabalhava com arquivos... tudo isso foi EXPANDIDO pela importação de bibliotecas. É tudo óbvio e todos os sistemas funcionam dessa forma. Mesmo agora a MQL pode trabalhar com arquivos apenas de uma caixa de areia. Não é que alguém esteja desafiando esta abordagem, é a política do desenvolvedor e todos a entendem e apóiam. Se você precisar sair de uma caixa de areia ou usar um registro para armazenar dados, ou um banco de dados ou mapeamento ... então, use bibliotecas para este fim. Certo? Tudo isso faz todo o sentido. A ferramenta não precisa de bancos de dados ou qualquer outra coisa... é tudo apenas para desenvolvedores, e é por isso que a linguagem MQL está disponível, para que você possa implementar ferramentas de qualquer funcionalidade. E como há um ambiente de desenvolvimento, a MT não é mais uma coisa em si mesma. )) Você só precisa ... ))))
Este tipo de pensamento e de cargos tem 10 anos, mas ainda estamos aqui.
Como ainda é esse o caso?
Todas as possibilidades de interoperabilidade já existem há muito tempo. O suporte DLL foi mesmo introduzido em 2004.
Nossos idiomas estão em constante evolução e se tornando mais poderosos e funcionais. E o ecossistema é mais poderoso do que qualquer outro.