Perguntas de um "boneco" - página 204
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
Tentei procurar interesse nos ficheiros de história do hcc.
Acontece que a linha de registos de dados dentro do binário hcc começa com FileSeek(handle,15333,SEEK_SET) , e parece
4 byte int Separador
4 byte int datetime
8 bytes duplo aberto
8 bytes duplo alto
8 bytes duplo Baixo
8 bytes duplo Fechar
1 ou 2 bytes int TickVolume
1 ou 2 bytes em Spread
e até 4 bytes Volume
E o comprimento das últimas duas ou três int's é determinado pelo primeiro Separador, tanto quanto eu entendi. Só não sei como. Poderia dizer-me como determinar 1 ou mais bytes serão os últimos 2-3 int's?
Uma dica, por favor...
Acho que adivinhei - Separador contém estrutura de leitura de dados em código de 16 bytes. Como Separator=18385028, em 16º a partir do bit mais baixo 4888811, ou seja 4 byte, 8 byte .... 1 byte.
Parece ser este o caso?
P.S. É exactamente assim que os ficheiros são lidos, só tem de saltar 189 bytes entre dias.
Agora compreendo porque é que os criadores não tornam estes ficheiros públicos. Não se trata apenas de sincronização com o servidor, mas parece que têm medo de ser censurados pela estrutura e organização dos ficheiros, como um verdadeiro "Woe from Wit". São demasiado baratos para adicionar Aski, mas para todos os tipos de resseguro contra a não sincronização, bem, fizeram um navio átomo inteiro "Lenin". Pessoalmente não compreendo todas estas perversões e estou triste.
Compreendo agora porque é que os criadores não tornam estes ficheiros públicos. Não se trata apenas de sincronização com o servidor, mas parece que têm medo de ser censurados pela estrutura e organização dos ficheiros, como um verdadeiro "Woe from Wit". São demasiado baratos para adicionar Aski, mas para todos os tipos de resseguro contra a não sincronização, bem, fizeram um navio átomo inteiro "Lenin". Pessoalmente não compreendo e sinto-me triste com todas estas distorções.
*Os ficheiros HCC são blocos comprimidos de dados, o que significa que não são directamente legíveis.
Estes ficheiros servem como dados de entrada para criar prazos de trabalho comprimidos, que são colocados na subdirectoria /cache.
Os ficheiros *.HCC são blocos de dados comprimidos, o que significa que não são legíveis directamente.
Estes ficheiros servem como fonte de dados para a criação de prazos de trabalho não comprimidos, que são colocados na subdirectoria /cache.
Renate. Porque é que o tornaram tão complicado? Justifica-se? Não sou um programador e provavelmente não entendi nada, mas olhar para a ordem das entradas é apenas assustador. É conveniente para o seu próprio trabalho?
Na verdade, claro, eu estava a olhar para ele para ver se conseguia escrever por cima dos ficheiros hcc. Mas depois de olhar para a sua complexidade, não quero analisá-los mais. Neste momento estou a ver as citações da FXCM em demonstração. Mas por alguma razão, a história é apenas a partir de Outubro. Tenho uma conta com eles, mas sem marcação com comissão. Há anos que utilizo o seu API para descarregar minutiae TS2 e também tenho utilizado o Pergunta. Eu queria implementá-los no MT5 para tornar os meus testes mais realistas. Mas agora não me apetece. Se os criadores não nos fornecerem a estrutura completa dos ficheiros hcc, teremos de fazer testes no MT4 utilizando scripts que leiam dados reais com Askas a partir dos ficheiros de história disponíveis. A propósito, FXOpen dá a história com Askas directamente em MT4. Isso é óptimo. É uma pena que não possam ser usados no testador. Mas pelo menos é possível testá-lo com guiões.
Tentei olhar para os ficheiros de história do hcc por uma questão de interesse.
Acontece, que a linha de registo de dados dentro do binário hcc começa com FileSeek(handle,15333,SEEK_SET)
e o que há nestes primeiros 15333 bytes, conseguiria descobrir?
Acho que adivinhei - o separador contém estrutura de leitura de dados em código de 16 bits. Como Separator=18385028, em 16º a partir do bit mais baixo 4888811, ou seja 4 byte, 8 byte .... 1 byte.
Parece ser este o caso?
hmm, parece que sim. acontece que o ficheiro é lido bloco a bloco, variando o tamanho do bloco em função do separador especificado.
P.S. É exactamente assim que os ficheiros são lidos, apenas entre os dias em que se tem de saltar 189 bytes.
Reparei que os dias começam realmente com o "cabeçalho". Em que vai o nome do personagem, etc. Provavelmente, este chapéu dá alguma informação quantitativa sobre os dados contidos neste bloco de dias.
PS
Não desista do assunto, porque é muito interessante criar os seus próprios minutos. A menos, claro, que o terminal os substitua durante outra sincronização com o servidor.Temos um formato de compressão muito eficiente; sem ele, haveria muitas vezes mais tráfego na rede.
Estou a trabalhar em Janelas não russas, definir a língua do MetaEditor para russo, mas quando chamo ajuda (F1), ela aparece em inglês. Pode dizer-me se há mais alguma coisa que deva ser mudada para russo, de modo a que a ajuda apareça em russo. Utilizo Windows russo em casa e está tudo bem.
E veja nos directórios, tem aí um ficheiro do Manual em língua russa?
Trabalho em Windows não russo, defino a língua do MetaEditor para russo, mas quando chamo ajuda (F1), ela aparece em inglês. Sabe se existe algo mais, que deveria ser mudado para russo, para fazer aparecer ajuda em russo? Em casa utilizo Windows russo e tudo é normal.
Depois de mudar de língua no MetaEditor, reiniciou-o?
Iremos verificá-lo.