Criação de uma GUI para MQLs em modo gráfico. - página 12
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
Na verdade, eu não tenho. Não há diferença entre um programa externo e um programa em MT. As capacidades são as mesmas, a interação é a mesma.
Você não explicou absolutamente nada. Como você obtém dados da MT* no painel sharpe?
Tenho feito feedback através do Memory Mapping com pesquisas cronometradas. O painel só me enviou configurações diferentes e resultados de cálculos lentos.
A ignorância dá confiança. Mas o conhecimento multiplica as tristezas.
Ok, então eu farei o painel separado, comunicação via Mapeamento de Memória. Eu costumava fazer isso através de tubos no final dos anos 2000, mas não gostava.
Porém, diretamente ligado, não notou horrores.
A interface COM do terminal seria legal, embora rapidamente se tornasse obsoleta.
Parece não se encaixar no tempo real :-(.
A interface COM provavelmente não estará disponível.
Mas posso perguntar por que está obsoleto?
Também está se tornando rapidamente obsoleto.
A interface COM provavelmente não estará disponível.
Mas posso perguntar por que está obsoleto?
Também está se tornando rapidamente obsoleto.
foi substituído por .net com suas interfaces de comunicação
foi substituído por .net com suas interfaces de comunicação
e só nos GUIA COM valem muito
A MS ainda compra de volta GUIDs não utilizados por um dólar a 10. Se você ainda tem algum remanescente dos velhos tempos, você pode ter um bom lucro!
E só nos GUIA COM valem muito
A MS ainda compra de volta GUIDs não utilizados por um dólar a dezena. Se você ainda tem algum remanescente dos velhos tempos, você pode ter um bom lucro!
Eu tenho alguns deitados por aí :-) Vou deixar você enviá-los para o MS
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
Se houver mais alguma coisa, talvez eu consiga encontrá-la.
Colegas. Penso que o argumento sobre qual ambiente de desenvolvimento é melhor e qual código é mais rápido não tem nenhum sentido. É tudo uma questão de gosto e depende das tarefas a serem resolvidas. Independentemente do ambiente de desenvolvimento, ainda temos problemas de interação entre uma aplicação externa e uma ferramenta MetaTrader. Vamos considerar um exemplo simples. Você implementou em uma dll nativa um algoritmo de cálculos matemáticos complexos. Você passou os parâmetros necessários da ferramenta MT para esta biblioteca e começou o cálculo, a ferramenta continuou seu trabalho até que o cálculo fosse concluído. E mais uma vez, esta questão não depende do ambiente de desenvolvimento!
Vejo várias opções:
1. A possibilidade de chamar de fora do método do programa OnChartEvent, usando, por exemplo, a PostMessage
2. Adicionando a МТ ferramentas novo método, como Renat ofereceu: OnExternal, especificando o tipo de evento ou dados geralmente transferidos, ou seja, neste método você pode retornar os dados
3. Implementação em MT de ferramentas de winsocket. Isto é semelhante ao segundo ponto, mas permite que a ferramenta MT se conecte a uma porta específica para ouvir os dados.
Se o primeiro e segundo itens permitirem a interação em um único nível de máquina, o terceiro item fornecerá ferramentas de MT com comunicação em rede.
Aqui está um exemplo:https://www.mql5.com/ru/articles/2599
Mas aqui novamente você tem o problema de ter que verificar se os dados no soquete estão disponíveis o tempo todo.
Portanto, o problema de callback permanece em todos os casos e não é resolvido.
O monitoramento do temporizador não é uma solução, mas uma muleta. Sim, na ausência de outras opções, é assim que estamos resolvendo isso agora.
Se os desenvolvedores implementassem uma solução para estas questões no nível da plataforma, então não haveria necessidade de acessar o terminal API. Afinal, não é pedido por causa da boa vida, mas porque não há uma interação plena entre a MT e as aplicações que estão sendo criadas. E repito: este problema existe independentemente do ambiente de desenvolvimento de aplicações externas escolhido.
Informações sobre a possibilidade de utilização de bibliotecas de rede ))https://www.mql5.com/ru/forum/13388
O tema é, em princípio, muito antigo. Os próprios desenvolvedores uma vez anunciaram a possibilidade de trabalhar com bibliotecas de rede sem dificuldades... Muita água correu desde então, mas a questão continua sem solução...
Ou aqui, uma mensagem do próprio Renat:https://www.mql5.com/ru/forum/3153/page2#comment_298866
https://www.mql5.com/ru/forum/3153/page2#comment_298892
Colegas. Penso que o argumento sobre qual ambiente de desenvolvimento é melhor e qual código é mais rápido não tem nenhum sentido. É tudo uma questão de gosto e depende das tarefas a serem resolvidas. Independentemente do ambiente de desenvolvimento, ainda temos problemas de interação entre uma aplicação externa e uma ferramenta MetaTrader. Vamos considerar um exemplo simples. Você implementou em uma dll nativa um algoritmo de cálculos matemáticos complexos. Você passou os parâmetros necessários da ferramenta MT para esta biblioteca e começou o cálculo, a ferramenta continuou seu trabalho até que o cálculo fosse concluído. E mais uma vez, esta questão não depende do ambiente de desenvolvimento!
Vejo várias opções:
1. A possibilidade de chamar de fora do método do programa OnChartEvent, usando, por exemplo, a PostMessage
2. Adicionando a МТ ferramentas novo método, como Renat ofereceu: OnExternal, especificando o tipo de evento ou dados geralmente transferidos, ou seja, neste método você pode retornar os dados
3. Implementação em MT de ferramentas de winsocket. Isto é semelhante ao segundo ponto, mas permite que a ferramenta MT se conecte a uma porta específica para ouvir os dados.
Se o primeiro e segundo itens permitirem a interação em um único nível de máquina, o terceiro item fornecerá ferramentas de MT com comunicação em rede.
Aqui está um exemplo:https://www.mql5.com/ru/articles/2599
Mas aqui novamente você tem o problema de ter que verificar se os dados no soquete estão disponíveis o tempo todo.
Portanto, o problema de callback permanece em todos os casos e não é resolvido.
O monitoramento do temporizador não é uma solução, mas uma muleta. Sim, na ausência de outras opções, é assim que estamos resolvendo isso agora.
Se os desenvolvedores implementassem uma solução para estas questões no nível da plataforma, então não haveria nenhuma necessidade de acessar a API do terminal. Afinal, não é pedido por causa da boa vida, mas porque não há uma interação plena entre a MT e as aplicações que estão sendo criadas. E repito: este problema existe independentemente do ambiente de desenvolvimento de aplicações externas escolhido.
Vou acrescentar sobre o monitoramento e sondagem, só que nem todos sabem disso - para evitar sacudir DLL em cada sondagem, você pode ter int[] para "compartilhar" bandeiras. Dentro da DLL todos os acessos a eles como __atômico__ .
Em princípio isto funciona e é bastante econômico em recursos, mas você tem que confiar no fato de que no lado MQL o incremento/decremento também são atômicos e o otimizador não faz suposições sobre valores.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Para tornar as coisas realmente boas, atributo atômico (volátil?) e um conjunto de primitivos apropriados seria suficiente. Na minha opinião, é mais fácil do que construir um novo mecanismo no sistema e não altera o protocolo DLL existente
Vou acrescentar sobre o monitoramento e sondagem, nem todos sabem disso - não para incomodar DLL com cada sondagem, você pode criar int[] para "compartilhar" bandeiras. Dentro da DLL todos os acessos a eles como __atômico__ .
Em princípio isto funciona e é bastante econômico em recursos, mas você tem que confiar no fato de que no lado MQL o incremento/decremento também são atômicos e o otimizador não faz suposições sobre valores.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Para tornar as coisas realmente boas, atributo atômico (volátil?) e um conjunto de primitivos apropriados seria suficiente. Na minha opinião, é mais fácil do que construir um novo mecanismo no sistema e não altera o protocolo DLL existente
Maxim, como esta solução é melhor? Afinal, a fim de verificar o status de uma bandeira, ela também precisa ser verificada periodicamente na MQL. Então, acontece que em qualquer lugar que você olhe, você precisa monitorar constantemente as mudanças do estado de algo para entender que está na hora de pegar os dados. E este fragmento pode ser armazenado na própria dll e verificado lá - é o que eu faço. Em seu exemplo, há uma chamada implícita para a dll para devolver o estado da bandeira.