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
Nota, Peter, como eu implementei um multigradiente de 6 cores.
onde p muda de 0 para 1.
ZS Mas há um problema com a cor mais externa, que eu ainda não consegui resolver.
Muito original. ) p é um número de usuário arbitrário, ou está vinculado a algum parâmetro?
Para que serve isto?
p=p*5;
Você pode enviar o número certo de uma vez. Depois desta linha p não retorna ao valor inicial.
Aqui:
você pode escrever:
e por que você não usa em vez de
int n=MathRound(p);
?
A função ARGB é uma função CCanvas padrão, ou é sua?
Existe, no entanto, uma falha com a cor mais externa, que ainda não foi corrigida.
Fixou-o:
O código acima foi corrigido.
A função ARGB é uma função interna da CCanvas, ou é sua?
ARGB é uma definição do CCanvas. Para descobrir, clique no ponteiro do mouse sobre o nome e pressione Alt+G
Para que serve isto?
5 é o número de cores -1
e por que você não a usa em vez de
ARGB é uma definição do CCanvas. Para descobrir, pressione o ponteiro do mouse sobre o nome e pressione Alt+G
5 é o número de cores -1
Ok. Eu não estava criticando, apenas perguntando. Você é ótimo em trabalhar com cores.
Você é ótimo com as cores.
Eu concordo. Mas há uma categoria de usuários que precisam disso de maneira diferente.
E se os dados retornados do indicador Kanvas excederem 512? Os amortecedores não vão ajudar neste caso. E os usuários só querem receber dados dos indicadores em seus programas. E eles não querem incorporá-los no corpo do Conselheiro Especialista (vou poupar uma coruja - deixá-la voar sem chocalhos no ...). E eles querem receber dados sobre qualquer barra solicitada, não apenas sobre as visíveis. E isto é justificado. E se justifica não apenas pela preguiça e desejo de obter tudo fácil e simples, mas também pelas exigências do TS.
Se estamos falando da grande maioria dos usuários que não são programadores, eles precisam ou da coruja ou do indicador. Eles não precisam de um indicador para a coruja.
Eu apenas dei algumas informações para pensar, não estou impondo nada. Deixe que os programadores decidam por si mesmos o que é conveniente e o que não é. No entanto, pessoalmente não acho que usarei a função iCustom em meus EAs.
Talvez eu não esteja muito certo.
É lógico supor que um usuário que comprou ou baixou tal indicador sem tampão de tela do Mercado desejará usar seus dados em sua EA.
Então o mais razoável para mim seria a troca através de uma estrutura especialmente criada pelo produtor deste indicador, que é lida através de um recurso.
O programador deve tomar cuidado em seu indicador Kanoval sem buffer que esta estrutura seja mantida no recurso atualizado, e fornecer ao usuário o arquivo inclu-file, no qual esta estrutura é lida usando os eventos dos usuários ou ao chegar de cada tick (não é razoável usar o timer, eu acho).
E o usuário teria que incluir apenas uma linha de código #incluindo... e então esta estrutura estará sempre disponível com dados reais do indicador.
Seria mais conveniente do que o uso clássico do iCustom, pois esta estrutura pode conter variáveis e conjuntos de dados de diferentes tipos (não apenas do tipo duplo, como nos buffers do indicador clássico).
Tenho quase certeza que os recursos da MQ são implementados da mesma forma que os amortecedores do indicador.
Acho que não estou muito certo.
É bastante lógico supor que um usuário que comprou ou baixou tal indicador canva do Mercado desejará usar seus dados em sua EA.
Neste caso, o mais razoável para mim seria a troca através de uma estrutura especialmente criada pelo produtor deste indicador, que é lida através de um recurso.
O programador deve tomar cuidado em seu canva indicador sem buffer que esta estrutura é mantida no recurso atualizado, e fornecer ao usuário o arquivo inclu- que lê esta estrutura usando os eventos do usuário.
E o usuário teria que incluir apenas uma linha de código #incluindo... e esta estrutura estará sempre disponível com dados reais do indicador.
Acho que é ainda mais conveniente do que o uso clássico do iCustom porque ele pode conter variáveis e vetores de dados convenientemente nomeados e o usuário não terá que se preocupar com o significado do número buffer e incluir apenas uma linha de código em seu programa para ter acesso total e conveniente aos dados indicadores.
Tenho quase certeza que os recursos do MQ são implementados da mesma forma que os amortecedores de indicador.
O mecanismo de transferência de dados através do próprio recurso é extremamente simples. É mais sobre o método de "comunicação" entre os dois programas. Um programa escreve, o outro programa lê. Portanto, o programa que escreve os dados (indicador) no recurso deve aderir ao formato de mensagem especificado e o programa que lê deve "conhecer" este formato. Então, a comunicação entre os programas será universal e eficiente.
O mecanismo de transferência de dados através do próprio recurso é extremamente simples. Trata-se mais do método de "comunicação" entre os dois programas. Um programa escreve e o outro lê. Consequentemente, o programa que escreve seus dados (indicador) para o recurso deve aderir ao formato da mensagem, e o programa que lê deve "conhecer" este formato. Então, a comunicação será universal e aplicável.
É claro que sim. Afinal de contas, a parte de recepção e transmissão é feita pelo único desenvolvedor que projetou o indicador em si.
O mecanismo de compartilhamento através de um recurso não é tão simples quanto isso. Isso requer certas habilidades. É o que eu vejo como uma vantagem deste método, pois será um privilégio para os programadores mais avançados.
ZS Peter, há um mês, não lhe pareceu que fosse extremamente simples e necessário. Ainda bem que você ouviu e entendeu minha mensagem. :))
É claro que sim. Afinal de contas, a parte de recepção e transmissão é feita por apenas um desenvolvedor, que desenvolveu ele mesmo este indicador.
O mecanismo de troca através do recurso não é tão simples assim. Isso requer certas habilidades. É o que eu vejo como uma vantagem deste método, pois será um privilégio para os programadores mais avançados.
ZS Peter, há um mês, não lhe pareceu que fosse extremamente simples e necessário. Ainda bem que você ouviu e entendeu minha mensagem. :))
Sim, Nikolai, os recursos provaram ser um método muito eficaz de intercâmbio de dados entre programas, e seu uso se baseia nos sindicatos de que você me falou (e Vasiliy também). Portanto, obrigado a ambos).
O próprio mecanismo de transferência de dados para um recurso e leitura a partir dele, é bastante simples, mas o formato da mensagem é uma questão complicada se você lutar pela universalidade. Se resolvermos o problema para um determinado indicador, tudo é simples.