Erros, bugs, perguntas - página 3121
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
Se o sabe, diga-me, por favor. Se carregar uma nova versão de um código existente no CodeBase, será a proibição de votar novamente para os programadores anteriores e estes poderão votar novamente na nova versão? Eu próprio duvido muito, mas se fosse possível seria justo repor a classificação anterior em vez da nova (que hipoteticamente não deveria ser inferior à anterior), uma vez que o código está a desenvolver-se e a nova versão poderia satisfazer o eleitor em maior medida, enquanto que a classificação antiga para o código antigo se tornaria inválida. (É verdade, à medida que a funcionalidade cresce o código também cresce, por isso pode haver novos bugs e falhas, ainda mais problemáticos. Qualquer coisa pode acontecer... e a nova pontuação pode ser mais baixa, mas para mim está bem).
Pare de arrancar o seu cabelo por causa da baixa classificação dos seus ...códigos. Se uma pessoa dá ao seu código uma pontuação de 1, isso não significa que seja o que é. Bem, reescreva-o pelo menos 100 vezes... e todas as 100 vezes este código será classificado dessa forma. É assim tão difícil de compreender?
Pare de arrancar o seu cabelo por causa da baixa classificação dos seus ...códigos. Se uma pessoa dá ao seu código uma pontuação de 1, isso não significa que seja o que é. Bem, refazê-lo pelo menos 100 vezes... e todas as 100 vezes este código será classificado desta forma. É assim tão difícil de compreender?
Talvez o seu currículo reflicta a realidade da votação e isso seja triste. Mas não estou triste comigo mesmo - aquelas estrelas virtuais não podem ser bebidas com chá e colocadas na minha carteira, estou frustrado com o conceito da forma como os produtos são apresentados aos novos utilizadores, preocupando-me especificamente com eles. Quando não existe uma classificação/classificação fiável, os utilizadores simplesmente não serão capazes de procurar eficazmente o produto que desejam com base no critério "classificar por classificação". Acontece que o sistema de classificação é um sistema vazio e é deixado à procura do produto certo pelo nome/descrição em vez de se confiar no número inútil de estrelas. Caso contrário, continuarão a pescar coisas... o que flutua na superfície (merecidamente ou não) e o que realmente precisam será ignorado. Estava apenas a sugerir que isto deveria ser alterado para ser mais ponderado. Mas se ninguém vai lutar contra essa realidade, eu lavo as minhas mãos dela.
O seu resumo pode reflectir a realidade da votação, o que é decepcionante. Mas não é comigo que estou triste - aquelas estrelas virtuais não podem ser bebidas com chá e colocadas na minha carteira, estou desapontado com o conceito da forma como os produtos são apresentados aos novos utilizadores, preocupando-me precisamente com eles. Quando não houver uma classificação/classificação credível, os utilizadores simplesmente não serão capazes de procurar eficazmente o produto que desejam com base no critério "classificar por classificação". Acontece que o sistema de classificação é um sistema vazio e é deixado à procura do produto certo pelo nome/descrição em vez de se confiar no número inútil de estrelas. Caso contrário, continuarão a pescar coisas... o que flutua na superfície (merecidamente ou não) e o que realmente precisam será ignorado. Estava apenas a sugerir que isto deveria ser alterado para ser mais ponderado. Mas se ninguém vai lutar contra essa realidade, eu lavo as minhas mãos dela.
Vamos dar uma vista de olhos ao seu código.
Cada tick desencadeia o acesso a variáveis globais, 4 pedidos de cada vez.
Daí resulta que NÃO PODE usar este código na sua máquina pessoal, pode usá-lo noutro lugar, onde não poupa o seu disco rígido.
Em loop in one loop durante a busca 3 vezes o ArraySize deve ser chamado , enquanto existem dois deles, isto é uma carga adicional no processador, isto também é indesejável, o desempenho do código cai.
DeInite eliminar objectos de uma forma estranha, não há nada de errado aqui, mas é um mau exemplo para principiantes, se o fizer normalmente, deve introduzir um prefixo ao criar objectos eeliminá-los sem recálculos excessivos.
Dou 2 pontos pelo vosso código.
Para o trabalho do indicador - não sei, não o executei.
Objectivo?
Bem, vamos dar uma vista de olhos ao seu código.
Em cada tick é accionado o acesso às variáveis globais, 4 pedidos de cada vez
Daí resulta que NÃO PODE usar este código na sua máquina pessoal, pode usá-lo noutro lugar, onde não poupa o seu disco rígido.
Em loop in one loop durante a busca 3 vezes o ArraySize deve ser chamado , enquanto existem dois deles, isto é uma carga adicional no processador, isto também é indesejável, o desempenho do código cai.
DeInite eliminar objectos de uma forma estranha, não há nada de errado aqui, mas é um mau exemplo para principiantes, se o fizer normalmente, deve introduzir um prefixo ao criar objectos eeliminá-los sem recálculos excessivos.
Dou 2 pontos pelo vosso código.
Para o trabalho do indicador - não sei, não o executei.
Objectivo?
1. Em cada tick há uma chamada para o GP, portanto em cada tick, e também em cada reinicialização (por exemplo, transições através de TFs) o código principal e mais pesado emOnCalculate() não é executado, e o indicador funciona mais rapidamente. O cálculo de novos dados - apenas com o aparecimento de uma nova barra baixa D1, que é muito mais rara, do que em cada carrapato.
2. Trabalhei ponderada e minuciosamente sobre o código, mas deixei algumas operações de comparação desnecessárias em if() porque sei com certeza que isso não afectará o desempenho.
3. Sobre o MUST não deve ser, é muito exagerado. Pode descarregá-lo e ver com os seus próprios olhos: o indicador voa.
4. Não sabia que os GPs são descarregados para o AF e depois lidos do mesmo local sempre que são acedidos numa sessão de MT5 em execução. Ainda penso que são lidos do LCD para a RAM uma vez quando inicio o terminal e vivo lá, e o indicador acede a eles na RAM, não ao LCD.
5. Não penso que o ArraySize() seja uma função dispendiosa. E mesmo que seja caro, não o notará neste código em particular. Provavelmente optimizaria esta função no meu primeiro indicador onde é utilizado com bastante frequência, enquanto que o próprio indicador é muito mais complexo e intensivo em termos de recursos.
6. Em OnDeinit() eu utilizo:
onde apenas há remoção pelo prefixo " l" (os nomes " label" e " line" foram utilizados na criação dos objectos.
7. Fez agora o que um utilizador que descarregou e compreendeu o código deve fazer. Encontrou as falhas - isto também faz parte da aprendizagem do MQL.
8. Conclusão: 1.) o meu principal argumento de código não ideal deste indicador - simplicidade, compacidade e velocidade... mais trabalho perfeito; 2.) o meu segundo argumento principal de código imperfeito - falta de analógicos mesmo maus em termos de velocidade e versatilidade (ver discussão sobre os originais de outros) e disponibilidade de melhorias em comparação com o original, que, a propósito, é estreito e não é dobrado em loops compactos em termos de grande número de blocos igualmente repetidos.
9. Apesar do ponto 7, não se compreendeu realmente o código de outra pessoa. A sua pontuação de 2 é demasiado baixa. Ainda não vos recomendaria que avaliassem os produtos de software pelo seu código. Não direi nada sobre objectividade porque é impossível esperar qualquer objectividade de um único utilizador. Uma estimativa objectiva (classificação) só é possível como uma soma de estimativas de vários utilizadores sãos e certamente não tem de ser necessariamente elevada.
1. Em cada tick há uma referência ao GP para que em cada tick, bem como em cada reinicialização (por exemplo, transições através de TFs) todo o código básico e mais pesado emOnCalculate() não seja executado, e o indicador funcione mais rapidamente. O cálculo de novos dados - apenas com o aparecimento de uma nova barra baixa D1, que é muito mais rara, do que em cada carrapato.
2. Trabalhei ponderada e minuciosamente sobre o código, mas deixei algumas operações de comparação desnecessárias em if() porque sei com certeza que isso não afectará o desempenho.
3. Sobre o MUST - muito exagerado. Pode descarregar e ver com os seus próprios olhos que o indicador voa.
4. Não sabia que os GPs são despejados no HDD e depois lidos a partir daí cada vez que são acedidos numa sessão MT5 em execução. Continuo a pensar que são lidos do HD para a RAM uma vez quando inicio o terminal e vivo lá, e o indicador acede a eles na RAM, não ao HD.
5. Não penso que o ArraySize() seja uma função dispendiosa. E mesmo que seja caro, não o notará neste código em particular. Provavelmente optimizaria esta função no meu primeiro indicador onde é utilizado com bastante frequência, enquanto que o próprio indicador é muito mais complexo e intensivo em termos de recursos.
6. Em OnDeinit() eu utilizo:
onde apenas há remoção pelo prefixo " l" (os nomes " label" e " line" foram utilizados na criação dos objectos.
7. Fez agora o que um utilizador que descarregou e compreendeu o código deve fazer. Encontrou as falhas - isto também faz parte da aprendizagem do MQL.
8. Conclusão: 1.) o meu principal argumento de código não ideal deste indicador - simplicidade, compacidade e velocidade... 2.) o meu segundo argumento principal de código imperfeito - a ausência de análogos em termos de velocidade e versatilidade (ver discussão sobre os originais de outros) e disponibilidade de melhorias em comparação com o original, que, a propósito, é estreito e não é dobrado em laços compactos em termos de grande número de blocos igualmente repetidos.
9. Apesar do ponto 7, não se compreendeu realmente o código de outra pessoa. A sua pontuação de 2 é demasiado baixa. Ainda não vos recomendaria que avaliassem os produtos de software pelo seu código. Não vou dizer nada sobre objectividade porque simplesmente não se pode esperar objectividade de nenhum utilizador. Uma estimativa objectiva (classificação) é possível apenas como uma soma de estimativas de alguns utilizadores sãos e não tem de ser necessariamente elevada.
A eliminação por prefixo é a seguinte: ObjectsDeleteAll(0, " pref_label"); // "pref_label" e " pref_line"
Adicione pelo menos a primeira linha à OnCalculate para tratar num novo bar e não em cada carrapato como é agora
Apagar por prefixo, é assim: ObjectosDeleteAll(0, "pref_"); // "pref_label" e " pref_line"
Adicione pelo menos se a primeira linha à OnCalculate, para que a referência esteja numa nova barra, e não em cada carrapato, como é agora
A propósito, relativamente ao ponto 7: tenho encontrado erros mesmo na documentação MQL5, que não são corrigidos há muitos anos.
Eliminar por prefixo é assim: ObjectosDeleteAll(0, "pref_"); // "pref_label" e " pref_line"
Apague-o da forma que sugerir não é razoável porque o início do prefixo é dinâmico: ou{D1}, ou {W1}, ou{MN1} e depois vem um prefixo inalterável como " l...". Pode trocar prefixos dinâmicos e estáticos e removê-los em segurança de acordo com a sua versão. Mas não é razoável porque é inconveniente tomar a informação como "R1{D1}", enquanto é mais conveniente usar "{D1} R1". Pensei em tudo isto há muito tempo e fiz exactamente como eu fiz.
Não há forma sensata de o apagar da forma que sugere, porque o início do prefixo é dinâmico: ou{D1} ou {W1} ou{MN1}, e depois há um prefixo imutável como " l...". Pode trocar prefixos dinâmicos e estáticos e removê-los em segurança de acordo com a sua versão. Mas não é razoável porque é inconveniente tomar a informação como "R1{D1}", enquanto é mais conveniente usar "{D1} R1". Pensei em tudo isto há muito tempo e fiz exactamente como eu fiz.
DrawTheLine("pref"+line_types[lt], StAinda assim, sim, em princípio, poderia fazer isso. Expliquei-me a mim próprio de forma elegante acima, pensando na altura sobre:
e não sobre nomes de objectos. O gráfico lê exactamente o que é definido comOBJPROP_TEXTpara etiquetas, mas os nomes dos objectos podem ser assinados de forma menos legível, porque estão escondidos e raramente lidos.
Por outro lado, na "Lista de objectos" (Ctrl+b) é melhor ver nomes de objectos legíveis, por isso o meu caminho é mais preferível. Além disso, há casos em que os nomes dos objectos têm de ser extremamente longos, pelo que"pref_" extra será completamente inaceitável.Ainda assim, sim, em princípio, poderia fazer isso. Expliquei-me a mim próprio de forma elegante acima, pensando na altura sobre:
e não sobre nomes de objectos. O gráfico lê exactamente o que é definido comOBJPROP_TEXTpara etiquetas, mas os nomes dos objectos podem ser assinados de forma menos legível, porque estão escondidos e raramente são lidos.
Por outro lado, na "Lista de objectos" (Ctrl+b) é desejável ver nomes de objectos legíveis, por isso a minha versão continua a ser preferível. Além disso, há casos em que os nomes dos objectos têm de ser extremamente longos, pelo que"pref_" extra será completamente inaceitável.e se alguém ainda tiver um programa com objectos gráficos, o seu tipo de prefixo "l" < onde basta apagar por prefixo " l" (os nomes "label" e "line" foram usados quando os objectos foram criados >
Irá matar todos os objectos que comecem por"l" num programa de terceiros. Esta não é uma boa solução