Domande da un "manichino" - pagina 204
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ho provato a guardare attraverso i file della storia di hcc per interesse.
Si scopre che la linea di record di dati all'interno del binario hcc inizia con FileSeek(handle,15333,SEEK_SET), e si presenta come
4 byte int Separatore
4 byte int datetime
8 byte doppio Aprire
8 byte doppio Alto
8 byte doppio Basso
8 byte doppio Chiudere
1 o 2 byte int TickVolume
1 o 2 byte int Spread
e fino a 4 byte Volume
E la lunghezza degli ultimi due o tre int è determinata dal primo separatore, per quanto ho capito. Non capisco come? Potreste dirmi come determinare che 1 o più byte saranno gli ultimi 2-3 int?
Un suggerimento per favore...
Penso di aver indovinato: il separatore contiene una struttura di lettura dei dati in un codice di 16 byte. Come Separator=18385028, in 16° dal bit più basso 4888811, cioè 4 byte, 8 byte .... 1 byte.
Vi sembra questo il caso?
P.S. Questo è esattamente il modo in cui i file vengono letti, solo che devi saltare 189 byte tra un giorno e l'altro.
Ora capisco perché gli sviluppatori non rendono pubblici questi file. Non si tratta solo di sincronizzazione con il server, ma sembra che abbiano paura di essere rimproverati per la struttura e l'organizzazione dei file, come il vero "Woe from Wit". Sono troppo economici per aggiungere Aski, ma per tutti i tipi di riassicurazione contro la non sincronia, beh, hanno fatto un'intera nave atomica "Lenin". Personalmente non capisco tutte queste perversioni e sono tristi.
Ora capisco perché gli sviluppatori non rendono pubblici questi file. Non si tratta solo della sincronizzazione con il server, ma sembra che abbiano paura di essere rimproverati per la struttura e l'organizzazione dei file, come un vero "Guai da Wit". Sono troppo economici per aggiungere Aski, ma per tutti i tipi di riassicurazione contro la non sincronia, beh, hanno fatto un'intera nave atomica "Lenin". Personalmente non capisco e mi sento triste per tutte queste distorsioni.
I file *.HCC sono blocchi di dati compressi, il che significa che non sono adatti alla lettura diretta.
Questi file servono come dati di input per creare i tempi di lavoro compressi, che sono collocati nella sottodirectory /cache.
I file *.HCC sono blocchi di dati compressi, il che significa che non sono leggibili direttamente.
Questi file servono come dati di origine per la creazione di tempi di lavoro non compressi, che sono collocati nella sottodirectory /cache.
Renate. Perché l'hanno reso così complicato? È giustificato? Non sono un programmatore e forse mi manca qualcosa, ma guardare l'ordine delle voci è semplicemente inquietante. È conveniente per il tuo lavoro?
In realtà, ovviamente, lo stavo guardando per vedere se potevo sovrascrivere i file hcc. Ma dopo aver visto la loro complessità, non voglio analizzarli ulteriormente. In questo momento sto guardando le quotazioni di FXCM in demo. Ma per qualche motivo, la storia è solo da ottobre. Ho un conto con loro, ma senza markup con commissione. Ho usato la loro API per scaricare le minuzie di TS2 per anni e ho usato anche Asks. Ho voluto implementarli in MT5 per rendere i miei test più realistici. Ma ora non ne ho voglia. Se gli sviluppatori non ci forniscono la struttura completa dei file hcc dovremo fare dei test in MT4 usando degli script che leggono dati reali con Askas dai file di cronologia disponibili. A proposito, FXOpen dà la storia con Askas direttamente in MT4. È fantastico. È un peccato che non possano essere utilizzati nel tester. Ma almeno si può testare con degli script.
Ho provato a guardare i file della storia di hcc per il bene dell'interesse.
Risulta che la linea di record di dati all'interno del binario hcc inizia con FileSeek(handle,15333,SEEK_SET)
e cosa c'è in questi primi 15333 byte, si potrebbe capire?
Penso di aver indovinato: il separatore contiene la struttura di lettura dei dati nel codice a 16 bit. Come Separator=18385028, in 16° dal bit più basso 4888811, che è 4 byte, 8 byte .... 1 byte.
Vi sembra questo il caso?
hmm, sembra di sì. risulta che il file viene letto blocco per blocco, variando la dimensione del blocco a seconda del separatore specificato.
P.S. Questo è esattamente il modo in cui i file vengono letti, solo che tra un giorno e l'altro bisogna saltare 189 byte.
Ho notato che i giorni iniziano davvero con la "testata". In cui va il nome del personaggio, ecc. Probabilmente questo cappello dà alcune informazioni quantitative sui dati contenuti in questo blocco giornaliero.
PS
Non abbandonate l'argomento, perché è molto interessante creare i vostri minuti. A meno che, naturalmente, il terminale non li sovrascriva durante un'altra sincronizzazione con il server.Abbiamo un formato di compressione molto efficiente; senza di esso, ci sarebbe molto più traffico di rete.
Sto lavorando su Windows non russo, ho impostato la lingua di MetaEditor in russo, ma quando chiamo aiuto (F1), appare in inglese. Puoi dirmi se c'è qualcos'altro che dovrebbe essere cambiato in russo, in modo che l'aiuto appaia in russo. Io uso Windows russo a casa e tutto va bene.
E guarda nelle directory, hai un file Handbook in lingua russa lì?
Lavoro su Windows non russo, ho impostato la lingua di MetaEditor in russo, ma quando chiamo aiuto (F1), appare in inglese. Sapete, c'è qualcos'altro, che dovrebbe essere cambiato in russo, quindi l'aiuto sarà visualizzato in russo? A casa uso Windows russo e tutto è normale.
Dopo aver cambiato la lingua in MetaEditor, l'hai riavviato?
Lo controlleremo.