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
Enviei os registos anteontem. Voltarei a contactar-vos... de alguma forma senti a falta... porque escreveu que reproduziu o erro.
Os registos estão dentro, obrigado. Analisámo-los. E a questão não era sobre os registos, mas sim sobre o ficheiro.
Reproduziram o erro, mas não imediatamente. Aparentemente não consertaram tudo - é preciso reproduzi-lo mais, mas não se está a reproduzir.
A questão não é sobre os registos, mas sim sobre o ficheiro.
O erro foi de facto reproduzido, mas não imediatamente. Aparentemente, não resolveram tudo - é preciso continuar a reproduzir, mas não está a reproduzir.
respondeu
Tive uma actualização rápida para 567, não notei quaisquer problemas. O voo está bem. :)
tol64:
Já tem tudo pronto até agora? )))
Até agora tudo bem também, só quero ter a certeza de que é uma construção nativa e não uma fundição. )))
joo: Всё на месте.
alexvd: Não se preocupe, a construção é nativa. Pode verificar as assinaturas dos ficheiros.Para a lista de prazos, para obter os seus nomes, existe EnumToString() - devolve o nome do prazo como uma cadeia. É possível obter como string os nomes das constantes de visibilidade de objectos incorporadas do tipo OBJ_PERIOD_M5?
Não, isto é de facto uma macro (#define), não está planeada nenhuma funcionalidade deste tipo para macros.
Existe alguma relação entre a estrutura da lista de prazos e as bandeiras de visibilidade dos objectos (porque mesmo a extensão das listas é diferente: 22 vs 23)? Em geral, peço a fim de atribuir de forma eficiente e compacta a visibilidade dos objectos em períodos de tempo num ciclo com determinados limites, em vez de listar e resumir as bandeiras manualmente. Que lógica usar se um prazo arbitrário for tomado ao acaso, um objecto gráfico é construído sobre ele e tem de ser permitido ser visível em todos os prazos não mais antigos do que o actual (isto é, o que foi construído sobre ele)? O algoritmo deve ser universal, e não para um caso em particular. A correlação do índice já está aparafusada, não há sequer uma correspondência do índice. Parsing strings de nomes e comparação é novamente um fracasso devido à impossibilidade de lidar com strings em caso de constantes de visibilidade. Até agora, vem-me à mente uma implementação complicada, vaga e muito tortuosa.