Um estúdio visual sobre a plataforma MT4. - página 4
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
Você pode ver como serão as informações técnicas e instruções sobre a criação da GUI para o motor gráfico, seguindo este link:
https://www.youtube.com/watch?v=ciVqJwgIIyg&feature=youtu.be#t=66.940294
Até onde eu sei, não existe atualmente nenhuma maneira de transferir uma interface criada no MS Visual Studio para um gráfico de plataforma MT.
...
Isto significa que o usuário estará completamente isolado do código e do compilador em todos os assuntos relacionados à criação da interface gráfica de seu programa, e só terá que lidar com as ferramentas de controle visual oferecidas pelo estúdio. O design da interface utilizará a tecnologia "drag and drop" e diferentes janelas de configuração, através das quais é possível definir as propriedades dos modelos e controles de janela prontos para uso.
...
... Este motor irá ...para fundir-se com a aplicação do desenvolvedor e realizar todo o trabalho gráfico.
Mas como se integraria com o aplicativo do desenvolvedor, se não via código? Suponha que um programa precise emitir uma tabela semelhante à Market Watch. Então, devemos enviar a ele a instrução de que "EURUSD" deve ser exibido na célula "A1", o preço "1,238273" deve ser exibido em A2, etc. Entretanto, um conjunto de ferramentas será diferente de terminal para terminal e estaticamente os campos e nomes das tabelas simplesmente não podem ser preenchidos.
Microsoft Visual Studio é tudo claro - é um prático complemento para... Este motor será preenchido de forma estática nos campos e nomes das tabelas. criação da aplicação. Ou seja, Visual Studio não é realmente um ambiente de desenvolvimento visual, e no caso de seu programa, não está claro como ele funcionará.
Mas como se integrará com a aplicação do desenvolvedor se não através do código? Suponha que o programa precise emitir uma tabela semelhante à Market Watch. Depois deve receber uma instrução de que "EURUSD" deve ser colocado na célula "A1", o preço "1,238273" em A2, etc. Entretanto, um conjunto de ferramentas será diferente de terminal para terminal e estaticamente os campos e nomes das tabelas simplesmente não podem ser preenchidos.
No Microsoft Visual Studio é claro - é um prático complemento paraambiente de software criando aplicações. Ou seja, o Visual Studio não é realmente um ambiente de desenvolvimento visual, e no caso de seu programa não está claro como ele funcionaria.
No momento, uma solução para combinar o motor gráfico e a funcionalidade da aplicação do usuário está em desenvolvimento.
Só posso apresentar-lhes o conceito geral.
Ao escrever sua própria aplicação, o desenvolvedor terá que salvar valores de variáveis retornadas por suas funções personalizadas (por exemplo, o valor do preço atual da licitação no "EURUSD") não dentro de sua aplicação, mas fora dela.
Isto significa que, ao invés de seus próprios nomes de variáveis, eles terão que escrever o índice de uma célula de matriz de memória compartilhada (localizada fora de seu programa) e armazenar o valor retornado pela função lá.
Esta matriz global eu chamo de "núcleo de parâmetros ". Em seguida, o usuário atribuirá o endereço desta célula ao controle no estúdio. Por sua vez, o motor gráfico faz um loop periódico através dos objetos e observa os endereços dos parâmetros ligados a eles no kernel do parâmetro. Se um valor nesse endereço tiver sido alterado por uma função do usuário, o motor o atualizará na janela. Ou vice-versa - se o valor tiver sido alterado por um controle, a função do usuário aceitará seu processamento.
Em essência, esta solução é uma simbiose de dois programas que se comunicam através de uma memória compartilhada, chamada "kernel de parâmetros". Ambos os programas, o motor GUI GUI e o programa do usuário, serão colocados em diferentes gráficos dentro do terminal.
O único problema é a criação da memória compartilhada. Tentando resolver isso com MQL, não quero recorrer a uma DLL, mas se não houver saída, você pode criar memória compartilhada lá. Eu já fiz isso.
O único problema é criar a memória compartilhada. Tentando resolvê-lo com MQL, eu não quero recorrer a uma DLL, mas se não houver saída, você pode criar memória compartilhada lá. Eu já fiz isso.
Por que você acha que sim? Há, e até mesmo alguns. Mas não está claro por que elas, as interfaces, devem ser transferidas para os gráficos - se assim for, provavelmente não existem. Mas é bastante realista sobrepô-los em cima da MT.
Uma vez que você recorre à DLL, não resta nada de seu conceito. Apenas nada - Pschich. Com uma DLL, e mesmo sem uma DLL, seu problema pode ser resolvido sem desenvolver absolutamente nada.
Seja específico, por favor.
Sobre o que ser específico? Criando janelas em VS em cima do MT? Este é um passarinho - em cima de todas as janelas.
Troca de dados com a VS? Pelo menos de 4 maneiras.
Por favor, explique sua opinião.
O único problema é criar a memória compartilhada. Tentando resolvê-lo com MQL, eu não quero recorrer a uma DLL, mas se não houver saída, você pode criar memória compartilhada lá. Eu já fiz isso.
É claro que você pode organizar a comunicação via DLL, mas ninguém vai precisar dela, porque o Mercado proíbe qualquer DLL. A única maneira de organizar o intercâmbio global de dados entre os dois programas, em termos de MQL padrão - é o intercâmbio através de variáveis globais. A propósito, aqui está uma biblioteca muito legal para o intercâmbio de dados através de variáveis globais:https://www.mql5.com/ru/code/12786.
Em geral, não está muito claro para quem você está criando seu estúdio. Se para os desenvolvedores sua solução não tem API. Ninguém quer arrastar uma aplicação separada, com a qual o programa irá trocar dados, especialmente para programas colocados no Mercado.
A solução com licença de usuário também, imho, é uma opção muito infeliz. Aqui está um programador desenvolveu um programa baseado em seu estúdio, pago pelo primeiro mês de trabalho, e depois, no segundo mês, seu programa não vai funcionar, porque o núcleo gráfico de seu estúdio exigiu outra taxa. Besteira. Nenhum desenvolvedor basearia seu projeto em um pacote que pedisse constantemente taxas adicionais. Mas mesmo que imaginemos que a licença será comprada como uma quantia fixa, e o próprio estúdio fará parte da aplicação, então novamente não está claro como funcionará no mercado (programa licenciado com outra licença dentro dele).
Ainda assim, responda à pergunta principal: para qual público-alvo seu projeto está sendo criado? Por que o usuário médio precisaria de seu estúdio? Você quer criar o Microsoft Word no MetaTrader 5? É claro que é legal, mas por quê? As pessoas pagam por soluções prontas. Para programas e algoritmos que fazem um trabalho específico. Eles não precisam criar formulários. Eles precisam de programas. E os programadores que escrevem esses mesmos programas não podem usar seu estúdio, porque o trabalho é organizado de uma maneira muito estranha.
Entenda que neste momento a ênfase deve ser colocada no mercado. Se você quiser criar um projeto de infra-estrutura, deve antes de tudo responder à pergunta: "Por que os programadores, que estão fazendo negócios no mercado, ou trabalhando em freelance, começarão a usar meu estúdio". O que lhes dará"?