Pedido inválido - apenas começou e não se consegue perceber... - página 6
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
Porquê, escrevi um para mim, mas para quatro.
Então, escreveu pessoalmente uma biblioteca universal, separada da lógica empresarial da EA e que pode ser utilizada em qualquer EA?
Eu também não acredito nisso. É claro que o código de resposta do servidor estava lá, mas tudo dentro da lógica empresarial, não como uma biblioteca universal.
Então escreveu pessoalmente uma biblioteca universal, separada da lógica empresarial da EA e que pode ser utilizada em qualquer EA?
Eu também não acredito nisso. É claro que o código de resposta do servidor estava lá, mas tudo dentro da lógica empresarial, não como uma biblioteca universal.
Sim, eu posso prová-lo. Por um preço, é claro.
Também não há biblioteca para o MT4.
Não foi assim tão difícil de provar.
Ou seja, também não há biblioteca para o MT4.
Não foi assim tão difícil de provar.
Renat, tenho a sensação de que a utilização da biblioteca padrão cai sob o refrão: "OOP ou não OOP".
Caso contrário, não consigo compreender porque é que as pessoas têm fortes convicções de que um invólucro OOP, que simplifica as operações comerciais, não deve ser utilizado.
Alguns reclamam um invólucro para fazer toda a lógica, lidar com erros, repetir consultas, etc. E ao mesmo tempo a sua utilização é supostamente perigosa e há um erro em cada linha...
Isto é, está lá.
não o tem. todos os erros são tratados pela lógica empresarial.
Utiliza a propriedade de sincronicidade no MT4, o que simplifica o processamento até certo ponto, mas os seus métodos não garantem 100% de todos os casos. Provavelmente 95% e isso é apenas a sua bíblia na qual todo o processo comercial se baseia.
Mas o MT5 é muitas vezes mais complexo em termos de tratamento de códigos de retorno + assíncrono.
Está a pedir o impossível de um invólucro. A biblioteca padrão não é lógica empresarial. É um invólucro "sobre" as funções do terminal. Um invólucro sobre o recheio de uma barra de chocolate.
É uma interface de fácil utilização que assume parte da rotina. Assumir o mesmo tipo de código. Não se come um invólucro de papel e queixa-se porque é que não é comestível. :)
Mas o invólucro não pode garantir nada, uma vez que é você que actua como fiador. A sua lógica empresarial. :)
Tal como a função Imprimir não pode garantir espaço livre no disco e erros de registo. É necessário utilizar outras funções para o tratamento de erros e elas são específicas para cada caso.
-Alexey-, vamos conversar sobre falhas específicas e você fala sobre as falhas específicas que gostaria de corrigir.Se quiser, pode percorrer cada código de retorno e ver as principais situações possíveis.
Responder às perguntas:
- porque arrastaria todos estes 61 métodos para trás de mim? É racional?
A questão vai no plano de saber se precisa ou não de programação OOP. Não posso responder-lhe sem ambiguidade.
Na minha prática utilizo o OOP para modelos de alto nível.
Claro, utilizo-o muito na minha base apenas nas funções.
De forma correspondente, quando utilizo uma classe OOP, contém muitas coisas desnecessárias para alguma tarefa em particular. É como a funcionalidade da biblioteca de desenho kanvas. Há linhas e quadrados e texto. Mas não há nada a discutir - se esta classe deve ter um quadrado ou não. Está mesmo ali. Para uma determinada tarefa.
Há demasiados problemas que estão a tentar resolver dentro de uma única classe.
está enganado. Eles não estão a resolver nenhum problema. enrolaram-se à volta da RUTINA. é difícil de compreender.
Consequentemente, o tratamento de erros deve ser para todas as tarefas a serem resolvidas.
Não pode estar lá. Uma vez que a bíblia não resolve nenhum problema. Simplifica o RUTINO. É tudo. Não pode fazer mais, e não precisa de ser complicado.
A solução é suficientemente simples: dividir uma classe incómoda em várias mais pequenas, de acordo com os problemas a serem resolvidos:
Neste caso, envolverei apenas as classes que se enquadram na minha estratégia e nada supérfluo. E será muito mais fácil de implementar o tratamento de erros do que é agora.
Bem, não é uma rotina de embrulho. Já é um solucionador de problemas com a lógica específica do SEU perito.
Não se pode prever o tratamento de erros mesmo numa única função - abrir ou fechar. 1001 casos são sempre encontrados, quando os erros previstos não se encaixam e é necessário fazer outra coisa.
Se conhece uma função universal para todas as situações, por favor mostre-a. Não consigo sequer imaginar como é possível prever com antecedência todo o tratamento de erros possíveis, sem conhecer a lógica de uma determinada EA.
Mesmo que eu faça tal função - contradiz todas as suas palavras mais elevadas - "voltou a fazer demasiado barulho".
E se aplicar o seu método de escrita de código através de macros com direcção (ORDER_TYPE_BUY / ORDER_TYPE_SELL), então as classes serão bastante compactas.
Onde está tudo isto?
Mas as macros também não têm tratamento de erros. São tratadas pela lógica comercial de um Expert Advisor em particular num determinado erro. Não é assim tão difícil de compreender que não existem situações universais.
Se Renat aprendesse a ouvir as sugestões do fórum e tentasse compreender o significado destas sugestões, o MT5 já estaria muito à frente do que está hoje nesta fase de desenvolvimento.
Renat continua a repetir - estamos num fórum técnico. Não podemos falar aqui de coisas abstractas.
Por isso, por favor, dê-nos algumas especificações. Vamos considerar os termos de referência, as funções comerciais de que necessita e os possíveis erros e como lidar com eles. ok?
Responder às perguntas:
- se preciso apenas de colocar uma ordem de mercado, ou uma ordem pendente, porque arrastaria todos esses 61 métodos atrás de mim? É racional?
- Se eu tenho uma posição aberta e preciso apenas de definir paragens, porque é que eu arrastaria toda essa funcionalidade com 61 métodos? É racional?
- Se tenho uma posição aberta com paragens que serão activadas quando o preço atingir o seu nível, porque devo arrastar todos estes 61 métodos? É racional?
Ninguém o está a proibir:
Qual é o objectivo de "separar as operações de comércio em diferentes classes".
É o mesmo como se tivesse diferentes EAs para abrir, fechar e modificar. Parece ser possível, mas ninguém o faz (com raras excepções, tarefas especiais).
E gosto muito da frase "se preciso apenas de colocar uma ordem de mercado ou uma ordem pendente, porque é que eu deveria arrastar todos esses 61 métodos comigo? Isso é racional"?
Haverá cerca de 100kb de despesas gerais de memória por Expert Advisor. Caramba...
A propósito, aqui está uma sondagem. Utiliza a biblioteca padrão para operações comerciais?
Francamente, eu não devia ter saído com o meu posto.