Minha abordagem. O núcleo é o motor. - página 24
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
Certo.
O motor que transporta a aplicação GUI simplesmente executa a mecânica dos controles (botões, campos de entrada, etc...).
Pressionar botões, caixas de seleção, entrada de texto e outras ações do usuário, direto de são passados para a aplicação do desenvolvedor.
A aplicação pode transferir seus dados para campos e tabelas.
Tudo é feito através de um simples arquivo de conexão.
Oh bem, isso é outro assunto então.
NET-dlls estão chegando agora à MT. Não é mais difícil fazer uma GUI em C-sharp para MT, e com mais funcionalidade. E como em qualquer caso todos os eventos estão em paus de MT, então os botões também. Bem, parafuso de análise, imho, mais fácil de DLL do que de Peter.
Em geral, o motor Peter, se alguém útil, só venderá no mercado, onde a DLL nizizzo.
Antes de mais nada, você está mentindo quando diz "sem nenhuma dificuldade". Você pode facilmente criar uma GUI em C#, mas para conectá-la a uma aplicação MQL?
Mostre-me um exemplo de uma conexão desse tipo. Isto é pelo menos uma muleta assustadora. Você tem que fazer tudo através de uma DLL. Enviar eventos, receber eventos...
Quanto esforço e tempo será necessário para desenvolver uma conexão SharpGUI com um aplicativo MT via DLL?
Quem o fará, diante da simplicidade da minha solução? Eu já tenho uma interface de conectividade. A questão da conexão é de meia hora (se várias janelas). Tudo é muito simples. Sem DLL.
Portanto, esta é uma idéia "moribunda".
Primeiro de tudo, você está mentindo quando diz que "não é nada demais". Fazer uma GUI em C# é fácil, mas conectá-la à aplicação MQL?
Mostre-me um exemplo de uma conexão desse tipo. Isto é pelo menos uma muleta assustadora. Você tem que fazer tudo através de uma DLL. Enviar eventos, receber eventos...
Quanto esforço e tempo seria necessário para desenvolver umainterface GUI Sharp com uma aplicação MT SEM DLL?
Quem o fará, diante da simplicidade da minha solução? Eu já tenho uma interface de conexão. A questão da conexão é de meia hora (se houver várias janelas). Tudo é muito simples. Sem DLL.
Portanto, esta é uma idéia "moribunda".
Tudo é a mesma coisa. Sem nenhuma complicação. Não há nenhuma diferença na função que você chama, aplicação ou DLL. Você vê complexidade nas funções de chamada?
Tudo é a mesma coisa. Não há nenhuma complicação. Não faz nenhuma diferença qual função você chama - o aplicativo ou a DLL. Você vê dificuldade em chamar funções?
Não. É sobre a memória onde os valores dos parâmetros têm que ser sincronizados. A memória tem que estar ou em um arquivo ou em uma memória de aplicação compartilhada na DLL (ou em outro lugar).
Mas este não é o ponto principal.
O GERAL:
Cada desenvolvedor terá que criar sua própria interface para se conectar a sua GUI em Sharp.
E por que isso seria necessário quando eu já tenho tudo funcionando?
Não. Trata-se da memória onde os valores dos parâmetros devem ser sincronizados. A memória deve estar em um arquivo ou na memória do aplicativo compartilhado na DLL (ou em outro lugar).
Mas este não é o ponto principal.
O GERAL:
Cada desenvolvedor terá que criar sua própria interface para conexão com a GUI em Sharp.
E por que isso seria necessário se eu já tenho tudo funcionando?
Você está sendo dramático).
Você está sendo dramático).
Nem um pouco. Eu conheço a situação. Eu fiz a interface entre uma aplicação MT e uma aplicação Sharpe, através de uma DLL escrita em C++. Uma dor terrível no cu. Você tem que trabalhar com visual studio e MT ao mesmo tempo. Em seguida, para executar aplicações em paralelo.
Mas o principal é que ninguém desenvolveu um formato de interação de peças de aplicação. Portanto, todos estarão agonizando por conta própria.
Nem uma gota. Eu conheço a situação. Eu fiz a interface entre uma aplicação MT e uma aplicação Sharpe, através de uma DLL escrita em C++. É uma dor de cabeça. Você tem que trabalhar com visual studio e MT ao mesmo tempo. Em seguida, para executar aplicações em paralelo.
Mas o principal é que ninguém desenvolveu um formato de interação de peças de aplicação. Portanto, todos estarão lutando por conta própria.
A DLL é uma ferramenta padrão do Windows. A interoperabilidade das DLLs tem sido desenvolvida e utilizada desde os tempos do DOS. Não há nenhum problema aí.
A DLL é uma ferramenta padrão do Windows. A interoperabilidade com a DLL tem sido desenvolvida e amplamente utilizada há muito tempo, desde os tempos do DOS. Não há nenhum problema aí.
A interação da Sharp com a DLL foi desenvolvida. E a interação de uma aplicação ICL com Sharp via DLL é um incômodo pessoal para o programador.
Ele precisa organizar a memória compartilhada e fazer suas chamadas de função com base na leitura de bandeiras.
Conseqüentemente, ele precisa acessar infinitamente a memória compartilhada que está na DLL ou no arquivo.Afinal de contas, não há retorno de chamada da Sharp via DLL para MT.
A interação com a DLL no lado Sharp é trabalhada. E a interação do aplicativo MKL com o Sharpe via DLL, é um incômodo pessoal para o programador.
Ele precisa organizar a memória compartilhada e fazer suas chamadas de função com base na leitura de bandeiras.
Conseqüentemente, ele precisa acessar infinitamente a memória compartilhada que está na DLL ou no arquivo.Afinal de contas, não há retorno de chamada da Sharp via DLL para MT.
Você também não tem uma ligação de retorno na MT. Tudo é feito por eventos pré-definidos na MT, que de uma vez por todas.
Você ainda enviará eventos terminais para a DLL, e não importa onde você os processa, em MT ou em DLL.
Mesmo que se imagine que a verificação constante das mensagens da Sharp por parte da aplicação ICL não seja um incômodo, desenvolver um formato de interação é uma tarefa muito volumosa.
Esta tarefa inclui o seguinte:
1. Com uma organização de memória compartilhada.
2. Implementando a interação das três partes.
3. Teste sincrônico dos três lados (Sharp, DLL, aplicação MT).
Muito demorado.
No meu caso, o usuário recebe o arquivo e o preenche. E a conexão funciona.