Discussão sobre "Como escrever uma DLL para MQL5 e trocar dados em 10 minutos". - página 3
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
Será possível criar dlls simples usando os meios mcl5? Em termos simples, escreva-os num unitor e compile-os...?
E onde obter o compilador e o linker com todas as bibliotecas Windows e plataforma SDK?
Pode fazer muito mais facilmente - descarregar e instalar gratuitamente o Visual Studio 2008 Express e fazer as DLLs necessárias no mesmo.
E onde obter o compilador e o linker com todas as bibliotecas Windows e plataforma SDK?
Pode fazer algo muito mais simples - descarregar e instalar gratuitamente o Visual Studio 2008 Express e utilizá-lo para fazer as DLLs necessárias.
A questão não é ser livre...
A questão é que tive de descarregar e instalar um monstro por causa de um monstro pequeno.
Seja como for, obrigado pela sua resposta...
Mais uma pequena pergunta...
O que precisa de ser descarregado a partir desta página:
http://www.microsoft.com/express/Downloads/
é
Visual C++ Edição Expresso 2008
ou todos
Todos - Instalar ficheiro de imagem ISO fora de linha
?
Visual C++ Edição Expresso 2008
É o suficiente.
Obrigado, estou a descarregá-lo agora.
Mas está tudo num só ficheiro (800 mb).
Não confio realmente na instalação da rede...
Criámos metodicamente 4 gerações de línguas comerciais desde 2001 com uma enorme comunidade de comerciantes. Os concorrentes estavam a morrer, as suas linguagens de controlo não estavam a desenvolver-se, mas nós estávamos a trabalhar, a trabalhar e vamos continuar a trabalhar.
Mas onde obter compilador e linker com todas as bibliotecas Windows e plataforma SDK?
Pode fazer muito mais facilmente - descarregar e instalar o Visual Studio 2008 Express gratuito e utilizá-lo para criar as DLLs necessárias.
Primeiro temos de descobrir o que são "suas" linguagens de controlo, delimitar "suas" funções e depois descobrir o que significa "seu" desenvolvimento. Não me refiro a concorrentes, mas sim a línguas. Como pode ver, os programas e sistemas de negociação vivem entre uma variedade de conchas circundantes, mesmo sob winndas temos C++/.net/JScript/shell script/ e outros, e outros, e corretamente apontados acima, que não faz sentido tentar arrastar tudo dentro da plataforma de negociação - criando algumas DLL, ou fornecendo temporizadores, troca de dados, etc., devem ser baseados em ferramentas já disponíveis e amplamente conhecidas do próprio SO, add-ons disponíveis gratuitamente. módulos (digamos, o desenvolvimento constante da estrutura .net com as suas versões de tempo de execução) + as mais poderosas ferramentas de desenvolvimento e depuração - porquê preocupar-se com uma bicicleta ou com a próxima geração de sistemas operativos como o sistema operativo cromado em todo o lado?
IMHO o desenvolvimento da linguagem de escrita TC deve servir as tarefas específicas do comércio, isto é, recolha de informação, análise, teste, gestão comercial e integração com outros sistemas - tudo isto pode e IMHO deve ser feito a um nível elevado de ferramentas de desenvolvimento modernas, isto é, integrando e alargando o quadro padrão seleccionado utilizando métodos geralmente aceites (OOP, etc.). A tarefa não é escrever uma plataforma auto-contida e auto-suficiente numa mistura de C / C + + ou o que quer que seja, mas antes de mais uma escrita de alta qualidade sobre as bases da plataforma de negociação, os seus serviços, API e interface de utilizador. Pois a tarefa de integrar a plataforma de negociação que já temos, mesmo que seja a melhor, é inevitável. Um exemplo simples é o AutoTrading. Provavelmente é claro que o arranque do Windows com autologin e o terminal МТ na pasta Start do SO - já é um anacronismo malicioso, precisamos de um serviço Windows normal para que os robots funcionem independentemente dos logins do utilizador (servidor?). A manipulação com DLL's pode não ser necessária, basear a plataforma, digamos, em .net. Escrever em C#, C++ gerido, Delphi, J++ e um monte de outras coisas. IMHO isto deveu-se ao medo dos programadores de tornar uma plataforma demasiado extensível e flexível que seria muito mais difícil de controlar do que qualquer caixa de areia com subscritores.
Quantas vezes já ouvi exactamente essas palavras - porquê reinventar a roda, porque não tomar java, Net, etc. como base. E eu próprio comecei a escrever as minhas primeiras estratégias de negociação exactamente há 11 anos, quando não havia qualquer ideia sobre API para uma conta de negociação.
Prepare o API de diferentes corretores e faça as suas próprias soluções, por amor de Deus.
Só que essa prática mostra que apenas os programadores exigem APIs em bruto. E para um programador pronto a ir "de mão em mão" para escrever o sistema, há 1000 comerciantes que querem testar as suas estratégias num quadro pronto e seguro.
Os novatos pedem API, por vezes recebem-no, e depois passa um mês de agonia e compreendem que o API para escrever até a estratégia comercial mais simples não é suficiente, e tudo o que eles precisam é de um ambiente de mercado pronto a fazer. Acontece que não há mercado para os programas mais simples sem API, que os compradores não estão interessados em estar vinculados a um terminal, etc. E o desejo de escrever mais é invariavelmente perdido.
O desenvolvimento normal de um ambiente de autoprogramação em plataformas comerciais requer uma estrutura segura com uma caixa de areia rígida, caso contrário ninguém partilhará scripts por medo de Trojans. Se não partilharem, a comunidade morrerá e a língua também.
A comunidade não é constituída por 50, 100 ou 500 programadores (que de bom grado lhe limparão os pés), mas por dezenas e centenas de milhares de comerciantes que utilizam sistemas com um mínimo de complexidade.
A propósito, apenas a MQL4.community recebe mais de 30 000 visitantes únicos todos os dias, e estimamos que existem mais de um milhão de utilizadores de MetaTrader 4 em todo o mundo.
Na construção 240 os invólucros foram simplificados, a taxa de chamadas é agora de 19.911.000 chamadas por segundo.
Quantas vezes ouvi estas palavras exactas - porquê reinventar a roda, porque não usar java, Net, etc. como base. Mas eu próprio comecei a escrever as minhas primeiras estratégias comerciais exactamente há 11 anos, quando não havia praticamente nenhum API na minha conta de negociação.
Essa é uma forma de o dizer. E mesmo depois de 11 anos algo tinha de mudar :)
Prepare o API de diferentes corretores e faça as suas próprias soluções.
Por vezes as pessoas sentem-se tentadas a fazê-lo. E porque não tentar melhorar a situação, especialmente se a posição o permitir?
Mas a prática mostra que apenas os programadores estão a exigir o API bruto. E para cada programador que está pronto para "escrever à mão" o sistema, há 1000 comerciantes que querem verificar as suas estratégias num quadro pronto e seguro.
O bruto é um conceito relativo. No entanto, por vezes um API é melhor do que nada. Ou pior, são forçados a utilizá-los devido às limitações inerentes à plataforma.
Sobre o tema de quadros "seguros", o debate é aberto, o que protegemos, de quem e como.
Os novatos exigem um API, por vezes recebem um, depois passa um mês de agonia e apercebem-se de que o API não é suficiente para escrever até a estratégia comercial mais simples, e precisam de um ambiente de mercado pronto para tudo o resto. Acontece que não há mercado para os programas mais simples sem API, que os compradores não estão interessados em estar vinculados a um terminal, etc. E o desejo de escrever mais é invariavelmente perdido.
É disto que estamos a falar - não API, mas uma estrutura extensível com interfaces especializadas, adaptadas a tarefas específicas! Ligar ao terminal não interessa a ninguém, mas os corretores "amam" ligar-se a si próprios. É claro que se tem de sentir pena deles.
Um ambiente normal de desenvolvimento para a autoprogramação em plataformas comerciais requer uma estrutura segura com uma caixa de areia rígida, caso contrário ninguém partilhará scripts por medo de Trojans. Se não partilharem, a comunidade morrerá, assim como a língua.
Permitam-me discordar aqui, mas estou aberto a mudar de ideias e a mudar de posição. Dê um exemplo da história da autoprogramação de plataformas comerciais onde o poder (excessivo) de um ambiente de desenvolvimento particular disponível superou o medo dos utilizadores e condenou tal ambiente à destruição e extinção. Concordam que permitir que as chamadas DLL na MT sejam assinaladas praticamente não resolve nada a este respeito, especialmente se houver uma razão justificável para recorrer a DLLs.
A comunidade não é de 50, 100 ou 500 programadores (que limparão alegremente os seus pés), mas de dezenas ou centenas de milhares de comerciantes que utilizam sistemas com um mínimo de complexidade.
É aí que precisa de se decidir desde o início, em vez de tentar fazer OOP para um tipo que tem uma vaga ideia de programação. Falando especificamente de sistemas de auto-negociação, dar aos negociantes um mínimo de complexidade e que crescerá para um máximo de complexidade sob o manto de uma interface gráfica (e, eventualmente, um pesadelo para o programador do sistema) - não será mais fácil não enganar ninguém e permitir a máxima flexibilidade na criação de sistemas, em vez de tentar encontrar um compromisso do que é permitido trabalhar para 95% dos casos (leia-se - "todos excepto alguns depenadores estão muito felizes, é assim que a nossa empresa se posiciona")?
A propósito, a MQL4.community recebe mais de 30 000 visitantes únicos todos os dias e estimamos que existam mais de um milhão de utilizadores de MetaTrader 4 em todo o mundo.
O que é que vai fazer com estas estatísticas? Claramente, em termos de negócios, as empresas de corretagem têm 98% dos comerciantes pobres que compraram um terminal de comércio com boa aparência e sem dúvida um terminal com todo o tipo de truques...
Caro pisara,
Sejamos claros - há uma discussão entre um teórico e um praticante. É claro que ninguém o proíbe de lutar pela "paz mundial", mas tenha em conta mais factores do que "porque não melhorar?
Ради бога, берите готовые API разнообразных брокеров и делайте свои решения.
Иногда к этому склоняют. А почему бы не постараться улучшить ситуацию, тем более если позиция позволяет?
Foi o que eu escrevi - não o usarão, porque não querem envolver-se em trabalho de rotina. Terá de obter tudo numa bandeja de prata - todos os indicadores, todo o ambiente do mercado, toda a história em diferentes períodos, etc. E terá de haver um gráfico, porque não manipulará todos os indicadores na sua mente.
Portanto, de facto, é necessário um terminal completo. E nós damos-lhe: MetaTrader 5 + MQL5 + DLL. Chame-lhe uma estrutura ou dê-nos apenas o terminal em código fonte/componentes (porque é isto que está a pedir).
Os programadores pensam erroneamente que é "poderoso" ser capaz de escrever scripts para sistemas comerciais em línguas nativas desprotegidas, e depois ficam surpreendidos por ninguém ir sequer usar as suas criações. É por isso que morrem antes mesmo de nascerem. Aqueles que desenvolveram e criaram uma comunidade de utilizadores pensam muito mais profundamente (porque já tiveram os golpes antes) e não cometem tais erros.
Chamada de DLL controlada (desactivada por defeito) é aceitável, mas descarregar DLLs feitas por outra pessoa para o seu terminal comercial é um buraco pior do que um Internet Explorer 6 não corrigido.
Para informação, estatísticas do Google Trends sobre terminais comerciais com automatização: