Desejos para MQL5 - página 81
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
A função SpeechText tem sido uma fonte constante de colisões. Como nem todos os sistemas operacionais o suportam da mesma forma. Em geral, o Speech SDK é um componente opcional e opcional do sistema operacional.
Após remover a função SpeechText padrão, os artesãos fizeram uma chamada de função análoga através de DLL. E os usuários desta DLL instalaram o componente acima mencionado. Não podemos forçar o usuário a instalar este componente ao instalar o terminal do cliente.
O que você pode fazer é criar sua própria dll "semi-oficial" e carregá-la aqui no fórum
Como um aplicativo (ou no site oficial) com uma breve descrição de como utilizá-lo (apenas para mostrar como importar a dll e executar o comando). Quem precisa dele, ele fará o download. E todos ficarão felizes.
.
- Ao longo do caminho - as dlls dos fóruns funcionarão na 5ª versão ou devem ser recompiladas?
- Ao longo do caminho, a pergunta - as dlls dos fóruns funcionarão na versão 5 ou será que precisam ser recompiladas?
>> Eles funcionarão.
Talvez alguém já me tenha dito ........ , mas eu gostaria que houvesse um bom ajuste de velocidade de visualização no testador.
Eu também gostaria que fosse possível testar EAs com várias moedas no testador não separadamente para cada par, mas para todos os pares ao mesmo tempo.
Para dizer a verdade, se eles adicionassem suporte Java nativo ao MT5, seria legal. Quero dizer, ter tanto MQL5 como JAVA com API para as funções do terminal.
Proponho introduzir o apoio nativo para a hora GMT. Isto seria uma garantia confiável de trabalho dos Consultores Especialistas, dependendo da abertura/fechamento das trocas, não dependendo do tempo restante definido no servidor DC e não exigindo chamadas de DLL do sistema e precisão (infalibilidade) das configurações do sistema local.
O tempo pode ser obtido via NTP (Network Time Protocol) em servidores disponíveis publicamente (por exemplo, time.windows.com) ou abra seu próprio servidor de tempo exato. A plataforma Linux tem ferramentas embutidas para a configuração de um servidor NTP, basta conectar um simples receptor GPS via porta COM ao servidor.
Não precisa de solicitações constantes ao servidor, apenas uma sincronização periódica (reconciliação) dos horários local e remoto.
Atualmente não há nenhum método na plataforma MT4 que dê 100% de certeza à GMT, e precisamos desesperadamente desta coisa.
Proponho introduzir o apoio nativo para a hora GMT. Isto seria uma garantia confiável de trabalho dos Consultores Especialistas, dependendo da abertura/fechamento das trocas, não dependendo do tempo restante definido no servidor DC e não exigindo chamadas de DLL do sistema e precisão (infalibilidade) das configurações do sistema local.
O tempo pode ser obtido via NTP (Network Time Protocol) em servidores disponíveis publicamente (por exemplo, time.windows.com) ou abra seu próprio servidor de tempo de precisão. A plataforma Linux tem ferramentas embutidas para a configuração de um servidor NTP, basta conectar um simples receptor GPS via porta COM ao servidor.
Não precisa de solicitações constantes ao servidor, apenas uma sincronização periódica (reconciliação) dos horários local e remoto.
Até hoje, a plataforma MT4 não tem nenhum método, dando 100% de confiança ao GMT, e isto é desesperadamente necessário.
Destacado.
Offset de 1) hora local e 2) hora do servidor em relação ao GMT em MQL5 sob a forma de variáveis de ambiente. Ele permitirá a realização de um algoritmo universal de processamento de dados históricos, incluindo a possibilidade de transferência sem problemas de Expert Advisors entre terminais de diferentes empresas de corretagem.
Para dizer a verdade, se eles adicionassem suporte Java nativo ao MT5, seria legal. Ter tanto MQL5 quanto JAVA com API para funções de terminal.
Por que Java, onde você obteve tal privilégio, o que há de tão "legal" nisso? Neste caso, sugiro adicionar ao suporte terminal o Ada, APL, Boo, COBOL, Componente Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1C, para que todos os desenvolvedores possam usar igualmente o MetaTrader em suas plataformas de desenvolvimento nativas.
Por que Java, por que tais privilégios, o que há de tão "legal" nisso? Nesse caso sugiro adicionar suporte para Ada, APL, Boo, COBOL, Componente Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1C para que todos os desenvolvedores possam usar igualmente MetaTrader em suas plataformas de desenvolvimento nativas.
Porque Java é legal, mas Ada, APL, Boo, COBOL, Componente Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1C são todos escória.
Porque Java é legal, mas Ada, APL, Boo, COBOL, Componente Pascal, Delphi, Eiffel, Forth, FORTRAN, Haskell, IronPython, Lexico, Lisp, Mercury, Mondrian, Nemerle, .Net Framework/ASP.NET, Oberon, Perl, PHP, RPG, Ruby, Silverlight, Smalltalk, Visual Basic, WFC, 1C são todos escória.
Bem, é exagero com o moolah.
Java, .Net, Delphi - necessário e suficiente.
Proponho a introdução do suporte de horário nativo GMT.
...
Apoiado por 10.000.000 mio %.
Operar em um único momento é toda uma série de benefícios.
(e, espera-se, muito mais do que aqueles que são a favor do "tempo misto").
O mais importante dos quais eu acredito:
- a escolha de negociação é ampliada a todos os disponíveis
- Atracagem ininterrupta e sem interrupções com recursos de informação