Erros, bugs, perguntas - página 1702
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
OK, como converter correctamente o dobro para int com o sinal intacto (o número não importa, se está fora do limite então limite-o para int)
Responder e depois fechar imediatamente.
Precisava de ser capaz de me apagar (o indicador) caso houvesse sequer uma cópia em execução, embora com parâmetros de entrada diferentes. Para o fazer, precisava de descobrir o cabo de mim próprio. Infelizmente, nessa altura não sabia que era impossível em MQL em 100% dos casos. Decidi portanto tentar um truque não muito inteligente.
Passei por todas as pegas. Se coincidir com o aleatório que escrevi no meu indicador antes de verificar, significa automaticamente que o cabo me pertence e posso apagar-me a mim próprio, se necessário.
Foi a partir destas considerações que um código tão inofensivo foi escrito, o que causou uma reacção tão ambígua, mas obviamente negativa por parte dos criadores. É que não se pode fazer isso. O que é que fez? Bem, li o valor do meu buffer através do CopyBuffer. É ilegal?!
Não há nada como "não se pode fazer isso" na resposta dos criadores. Em lado nenhum diz que é "ilegal".
Se pensa que precisa absolutamente deste "código inofensivo" - utilize-o. Basta adicionar IndicatorRelease(handle)) à OnCalculate() após a leitura do buffer. Não precisa de verificar em cada tick que é "seu" indicador, pois não?
É assim que o indicador resolve o seu problema e deixa de ser "invisível":
Que a comunidade esteja ciente de que é possível criar desta forma um fundo de execução descontrolada de qualquer código, mesmo no terminal sem gráficos. Aqui está uma pequena ponta dos pés. Considerá-lo ou não um insecto é provavelmente uma questão de terminologia. O meu entendimento é que os criadores não são capazes de mudar nada arquitectonicamente aqui. É por isso que existe tanta raiva. Não posso explicar esta reacção de qualquer outra forma.
Não há "raiva" na resposta do servicedesk. Há um mal-entendido sobre a sua motivação para exagerar regularmente os problemas com que se depara.
Os criadores são capazes de mudar as coisas. Mas são normalmente muito cuidadosos com sugestões para "retirar e proibir" mesmo comportamentos não documentados, se não forem inequivocamente prejudiciais. Este "hack" é bastante específico, mas talvez alguém o esteja a utilizar.
Talvez ainda haja edições no terminal sobre isto, mas certamente não é um problema gigantesco e a prioridade desta questão é mínima.
Ninguém se pronunciará de qualquer forma. Um tal ancinho estaria bem reflectido na Ajuda.
Acontece que está bem ciente de que este "grave bug" do terminal só lhe interessa a si.
Vamos encerrar o assunto nesta altura. Os detalhes técnicos foram todos discutidos, enquanto que as emoções são desnecessárias neste fio.
Não há nada como "não é permitido" na resposta dos criadores. Em lado nenhum diz que é "ilegal".
Se pensa que este "código inofensivo" é absolutamente necessário para si - utilize-o. Basta adicionar IndicatorRelease(handle)) à OnCalculate() após a leitura do buffer. Não precisa de verificar a cada tick que é "seu" indicador, pois não?
Não, claro, não há tal necessidade.
É desta forma que o indicador resolve o seu problema e deixa de ser "invisível":
Sobre este tema, recebi recentemente uma resposta do vosso colega
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
Erros, bugs, perguntas
Slawa, 2016.09.07 17:17
fxsaber:
IndicatorRelease após o iCustom deve ser feito?
Para quê?
Não o faça. Também não o fazer após o IndicadorCriar
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Insectos, insectos, perguntas
fxsaber, 2016.09.07 17:27
Depois não significa imediatamente. Mas se não tem de o fazer, quando é que o deve fazer?Não há "raiva" na resposta do servicedesk. Há um mal-entendido sobre a sua motivação para exagerar regularmente os problemas que enfrenta.
A motivação é puramente egoísta. Quero que tudo funcione de forma previsível, de acordo com a documentação. Os insectos são irritantes, esse é o resultado.
Os promotores estão em posição de mudar. Mas são normalmente muito cautelosos quanto a sugestões para "retirar e proibir" mesmo comportamentos indocumentados, a menos que seja claramente prejudicial. Este "hack" é bastante específico, mas talvez alguém o esteja a utilizar.
Talvez ainda haja edições no terminal sobre isto, mas certamente não é um problema gigantesco e a prioridade desta questão é mínima.
Estou de acordo quanto à prioridade.
Acontece que está bem ciente de que este "bug sério" do terminal é interessante apenas para si.
Terminemos esta pergunta neste ponto. Todos os detalhes técnicos são discutidos, mas as emoções são desnecessárias neste tópico.
Não preciso disso assim, estou a tentar fazer muito trabalho para facilitar a minha vida no futuro.
Resolvi o meu problema desta forma nos pais todos protegidos e a herança fica sob protecção e depois sobrepõe-se.
Só que agora já não é claro o que se pretendia inicialmente.
Parece que só se livra de métodos indisponíveis na lista pop-up.
Parece que basta ver-se livre dos métodos indisponíveis na lista popup.
Não só isso, reescrevi as classes de objectos gráficos para mim e de uma classe em que todas as propriedades dos objectos são descritas, agora facilmente e compreensivelmente (pelo menos para mim) faço os descendentes do tipo Botão.
Além disso, a partir destes elementos simples posso construir elementos mais complicados com probabilidade mínima de erro, velocidade máxima e simplicidade (pelo menos, para mim).
Talvez me dê um pontapé amigável e diga que a biblioteca padrão tem tudo, mas digo-lhe desde já, não é tudo e é tudo incompreensível. Estou habituado a trabalhar com o que entendo completamente, e a compreender como tudo funciona, é preciso experimentar tudo sozinho...
Então os inacessíveis não aparecem, pois não?
Não, eles sim.
A propósito, o mesmo se passa no estúdio.
Não, eles sim.