Desejos para MQL5 - página 28
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
talvez isto já tenha sido dito....
1) adicionar a capacidade de compilar quando criptografado e com a capacidade de gerar um número de série vinculado a um ID de computador (análogo ao do empacotador Armandillo),
tudo isso deve ser feito internamente dentro do tradutor e não da fonte
2) Adicionar possibilidade de trabalho interativo com programas externos o que permitiria gerenciar terminais de outros programas, conectar/desconectar ao servidor, verificar conexão ao servidor, pedir cotações de arquivo, fazer pedidos... etc.
3) possibilidade de fazer pedidos independentemente dos carrapatos recebidos
4) Suporte de trabalho simultâneo com vários DT/contas
5) Reviver a depuração de DLL
6) Pelo menos acrescentar apoio às estruturas, em geral seria desejável ampliar as possibilidades, para que elas se tornem mais semelhantes ao c++
Você precisa adicionar um link executável à ajuda que o programa oferece (por exemplo, para abrir uma janela com o texto desejado) e à página web.
Se o usuário faz algo incompreensível, o programa lhe diz: aqui está uma consulta sobre a situação, leia-a corretamente e não faça nada estúpido novamente.
SK,
Por exemplo, você deve definir TP=2 e SL=10 uma vez e depois só comprar ou vender, ou seja, o pipsing será muito conveniente. Devido a este inconveniente, fiz recentemente um Expert Advisor especialmente para definir TP e SL com os valores especificados depois que eu clicar em Comprar ou Vender.
Tantos desejos para tudo! 28 páginas já!
Eu gostaria de ouvir dos desenvolvedores que já estão em desenvolvimento, o que nunca será implementado e que pode ser implementado.
Caso contrário, não está claro se devemos desejar algo mais, nenhum feedback é visível.
Naturalmente, também queremos saber o momento. Entendo que prever os termos de lançamento de software às vezes não é mais fácil do que prever o movimento das taxas de câmbio.
Pelo menos sob esta forma: "A versão beta do MT5 será lançada não antes do que em .............". É possível escrever tal frase?
Caso contrário, não está claro se há algo mais a ser desejado, nenhum feedback é visível.
Tem-se falado em reatribuir a Magic em uma ordem ativa? A idéia é simples: no comércio de múltiplos períodos, será possível passar a ordem para um prazo maior quando a tendência for longa.
Tem havido alguma conversa sobre reatribuição de Magic em uma ordem ativa? A idéia é simples: no comércio de múltiplos períodos será possível passar a ordem para um prazo maior quando houver uma tendência longa.
Em resumo: uso a mesma estratégia comercial durante 4 períodos, ou seja, princípios de entrada/saída/trailing usando um algoritmo (um conjunto de indicadores e tipos de sinais), mas os parâmetros dos indicadores são diferentes para cada período (na verdade são 4 EAs em um gráfico), divisão por Magic. O resultado é o seguinte: em prazos mais baixos há todas as indicações para fechar posições muito mais cedo do que a situação do mercado realmente merece (ou seja, qualquer oscilação para o lado errado resulta em lucro), embora em prazos mais altos a situação seja muito estável. Ela afeta a volatilidade relativa dos indicadores. Acho que a idéia é clara - se situações estáveis ocorrem em períodos de tempo sênior, as posições em aberto nos juniores não devem ser fechadas, mas ao mudar a Magia elas devem ser passadas para a lógica dos períodos de tempo sênior. O aplicativo é realmente utilizado não apenas para prazos, mas para transferência para outras lógicas de processamento. Parece-me que não haverá problemas para a corretora, pois o bilhete permanece e o lucro pode ser encontrado.
Em resumo: Utilizo uma única estratégia comercial por 4 períodos, ou seja, princípios de entrada/saída/trailing usando o mesmo algoritmo (um conjunto de indicadores e tipos de sinais), mas os parâmetros dos indicadores são diferentes para cada período (na verdade são 4 Expert Advisors em um gráfico), divisão por Magic. O resultado é o seguinte: em prazos mais baixos há todas as indicações para fechar posições muito mais cedo do que a situação do mercado realmente merece (ou seja, qualquer oscilação para o lado errado resulta em lucro), embora em prazos mais altos a situação seja muito estável. Afeta a volatilidade relativa nos indicadores. Acho que a idéia é clara - se situações estáveis ocorrem em períodos de tempo sênior, as posições em aberto nos juniores não devem ser fechadas, mas mudando a Magia elas devem ser passadas para a lógica dos períodos de tempo sênior. O aplicativo é realmente utilizado não apenas para prazos, mas para transferência para outras lógicas de processamento. Parece-me que não haverá problema para a DC, porque o bilhete permanece, e podemos ter algum lucro.
O significado é claro.
Mas não creio que haja necessidade de mudar a linguagem e a tecnologia de comunicação entre o terminal e o servidor em prol desta idéia. Afinal, tudo o que você precisa pode ser contabilizado no programa no lado do terminal. Além disso, a própria idéia de mudar o majestoso demonstra eloquentemente o subdesenvolvimento da estratégia, seus critérios. A magia (como mostra claramente seu exemplo) não suporta e não pode suportar um critério fixo para fechar ou abrir uma ordem. Simplesmente porque um majik não está relacionado de forma alguma com o mercado.
Na minha opinião, este é um dos pontos-chave no comércio. Aconteceu que tínhamos um magik em nossas mãos, e nos amarramos a ele. De fato, devemos considerar a situação em cada novo tick como nova sem nenhuma pré-história (histórico de eventos na conta do jogo, incluindo tempo e preço de abertura de ordens de mercado).
E a magia é, embora parcialmente útil, mas na minha opinião, não é um mecanismo muito conveniente para acompanhar... quem sabe o quê. Acredito que se uma ordem pudesse ser identificada de forma única (na reabertura e fechamento parcial), o magik se tornaria sem sentido.
O ponto é claro.....
Vou tentar fazer alguns argumentos, vou começar do final...
Na minha opinião, se aceitarmos a ordem como um objeto, então a magia no momento é uma propriedade totalmente variável deste objeto do ponto de vista da programação, assim como os níveis SL ou TP. Posso estar errado, mas atualmente é impossível identificar claramente uma ordem em MQL em relação a um código executado no terminal em todas as etapas possíveis de sua vida (durante a reabertura e o fechamento parcial) e a magia em grande parte compensa esta situação. A magia não deve ser ligada ao mercado - ela simplesmente tem outra aplicação e não tem sentido, exceto por seu significado.
Não concordo com você em sua posição de ver a situação do mercado como uma situação sem história... Mas esta é a minha própria opinião. Se a ordem for lucrativa, devemos olhar para o prazo mais alto para tomar uma decisão e esperar por um pequeno recuo e continuar trabalhando com a ordem em um prazo mais alto ou simplesmente fechá-la, pois ela não vai dar frutos.
Não vou discutir a solidez e a pobreza da estratégia - concordo plenamente... Mas eu estou trabalhando nisso :-)
Mudar o idioma e o protocolo de troca entre o servidor e o terminal, bem, eu não sei ... No momento o valor majestoso já está lá e é aceito pelo servidor ao fazer um pedido. Não conheço o formato do protocolo de intercâmbio, mas suspeito que se trata de transmissão em lote de alguma estrutura de dados via transporte com posterior verificação de consistência. Acho que não é muito difícil acrescentar mais um parâmetro opcional à estrutura de dados transmitida pela OrderModify. Duvido profundamente que os desenvolvedores tenham tomado um caminho de protocolo de intercâmbio atômico e assim se atolaram em um processo pesado de suporte de versões.
Mas em geral eu só perguntei sobre os planos :-) Não, não.