Criação de uma GUI para MQLs em modo gráfico. - página 14
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
Eu tenho um TS externo, não preciso do feedback da GUI do terminal.
Então você não usa um terminal? Você está negociando telepaticamente?
Então você não usa um terminal? Comercializando telepaticamente?
Honestamente não senti a necessidade de anexar formulários aos gráficos.
Há um gráfico ativo que está diretamente ligado ao gráfico (todos os tipos de linhas, legendas, letras e assim por diante).
Mas existem controles GUI - configurações, relatórios, estatísticas. E eles são bastante grandes e é um crime contra o usuário colocá-los dentro de um gráfico :-)
Basta colocar o formulário no topo do gráfico. Você precisará remover o formulário do gerenciador de janelas e acompanhar as mudanças na geometria e no foco do gráfico.
update/ prestes a colocar o formulário - para colocar o RectLabel no gráfico e nos eventos do gráfico para acompanhar a mudança das cordinatas. Quando você o trocar, coloque seu formulário estritamente em cima :-) Você precisa de um pouco de pandeiro ao trocar as abas, minimizar a janela, para esconder sua forma a tempoTal "pôr-do-sol à mão" :-) Pelo menos você não vai entrar nas entranhas do MetaTrader e não vai impor novos arrepios e ganchos em suas janelas - ou seja, você vai se comportar decentemente
Qualquer GUI chamada da DLL tem a característica mais desagradável - Conselheiros/indicadores especializados que a chamam reiniciarão periodicamente por causa do menor espirro. O que leva à reabertura de formas e quedas d'água de linguagem grosseira.
Talvez os "serviços" há muito anunciados (ou como quer que sejam chamados) fiquem desprovidos deste inconveniente.
Eu não concordo. Se os pedidos forem abertos usando GUI, como em seu primeiro exemplo, o formulário correspondente deve pertencer ao gráfico correspondente. Por exemplo, você tem 5 gráficos abertos e destes 5, os formulários de gerenciamento de pedidos são abertos (não relatórios ou configurações). Os 5 formulários gratuitos "pertencentes" a diferentes gráficos confundirão e confundirão os usuários. E quando apenas a forma que pertence ao gráfico ativo está diante de seus olhos, é uma questão diferente.
Eu discordo. Se a GUI for utilizada para abrir pedidos, como no seu primeiro exemplo, então o formulário correspondente deve pertencer ao gráfico correspondente. Por exemplo, você tem 5 gráficos abertos e, destes cinco, os formulários de gerenciamento de pedidos estão em execução (não relatórios ou configurações). Os 5 formulários gratuitos "pertencentes" a diferentes gráficos confundirão e confundirão os usuários. E quando apenas a forma que pertence ao gráfico ativo está diante de seus olhos, é uma questão diferente.
A propósito, há também uma mesa (árvore) de encomendas, mas é apenas um exemplo...
A principal pergunta que os usuários têm é "como colocar cartas/formulários" em 3 monitores :-) Sem abas durante o comércio - tudo deve estar visível
)) o terminal é o provedor de dados e. o receptor executor da aplicação. É isso aí. Não há nada para se instalar nele.
Você está brincando comigo ou isto é algum truque? Há dois dias estou tentando obter uma resposta. Que canal o segundo receptor utiliza para receber estes pedidos? Talvez você devesse ser um escoteiro. Se forem apanhados, acenarão com a mão, cuspirão e deixarão em paz, ainda é uma retaguarda...
Você está brincando comigo ou isto é algum truque? Estou tentando há 2 dias obter uma resposta - que canal de comunicação o segundo - o receptor-executor recebe estes pedidos???? Por que você não se junta aos escoteiros? Se eles forem pegos, vão acenar, cuspir e deixar você em paz, é tudo uma retaguarda de qualquer maneira...
Alexei, meu palpite é que o esquema é o seguinte: cada gráfico tem uma EA que envia dados para a aplicação. Estes são os fornecedores de dados. Há uma EA em um gráfico separado que pesquisa o pedido de comandos. Este EA aceita pedidos e os executa. Como resultado, os EAs nos próprios gráficos não estão ocupados com o download de pesquisas. Eles enviam os dados e continuam trabalhando em seu modo. E uma EA separada está sempre envolvida em pesquisas de opinião.
Mas não vejo a necessidade de um Conselheiro Especializado separado. A sondagem pode ser tratada pelo indicador porque estará em uma linha separada da EA. E quando o indicador revela uma ordem para este quadro, ele pode enviar um evento que será interceptado e executado pelo Expert Advisor.
Alexei, acredito que o esquema é o seguinte: cada gráfico tem uma EA que envia dados para o aplicativo. Estes são os fornecedores de dados. Há uma EA em um gráfico separado que pesquisa o pedido de comandos. Este EA aceita pedidos e os executa. Como resultado, os EAs nos próprios gráficos não estão ocupados com o download de pesquisas. Eles enviam os dados e continuam trabalhando em seu modo. E uma EA separada está sempre engajada em pesquisas de opinião.
Mas não vejo a necessidade de um Conselheiro Especializado separado. A sondagem pode ser tratada pelo indicador porque estará em uma linha separada da EA. E quando o indicador detecta uma ordem para um determinado gráfico, ele pode enviar um evento que será interceptado e executado pelo Expert Advisor.
Estou me lixando se está dividido em 5 EAs ou 100500. Eu estava perguntando sobre o canal de comunicação, pois pode haver vários tipos. Mais uma vez, eu estava fazendo isso há 10 anos atrás em oleodutos. Naquela época, não havia mql de pips embutidos, eu usava C++DLL nativo. E o robô inteiro estava em Sharp. Os comandos do Expert Advisor foram acumulados no buffer DLL, porque foram emitidos de forma assíncrona para velocidade. E o MQL4 Expert Advisor acessou a DLL a cada tick (ainda não tinha temporizador), passou as aspas e pegou os comandos. Tudo era multimoedas, não entendo porque precisamos de muitos gráficos.
Aqui, descrevi o mecanismo de troca em duas linhas. É tão difícil descrever seu mecanismo ao invés de um oceano de água?
Aqui, descrevi o mecanismo de troca em duas linhas. É tão difícil descrever seu mecanismo ao invés de um oceano de água?
Merda. Primeiro eu perguntei sobre a GUI - como ela se comunica? Ele respondeu - de jeito nenhum, não é necessário. Agora, ao que parece, ele precisa de como os conselheiros se comunicam. 100 vezes escreveu sobre isso.
Você é realmente incapaz de responder a perguntas. Não estou interessado em como os conselheiros se comunicam. É isso aí, estou fechando o fio, porque é inútil.
Estou me lixando se está dividido em 5 conselheiros ou 100500. Eu estava perguntando sobre o canal de comunicação, pois pode haver vários tipos. Mais uma vez, eu estava fazendo isso há 10 anos atrás em oleodutos. Naquela época, não havia mql de pips embutidos, eu usava C++DLL nativo. E o robô inteiro estava em Sharp. Os comandos do Expert Advisor foram acumulados no buffer DLL, porque foram emitidos de forma assíncrona para velocidade. E a MQL4 Expert Advisor acessou a DLL a cada tick (ainda não tinha temporizador), passou as aspas e pegou os comandos. Tudo era multimoedas, não entendo porque precisamos de muitos gráficos.
Aqui, descrevi o mecanismo de troca em duas linhas. É tão difícil descrever seu mecanismo ao invés de um oceano de água?