Preguntas de un "tonto" - página 204
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Traté de buscar en los archivos de la historia de hcc por interés.
Resulta que la línea de registros de datos dentro del binario hcc comienza con FileSeek(handle,15333,SEEK_SET) , y tiene el siguiente aspecto
4 bytes int Separador
4 bytes int datetime
Doble de 8 bytes Open
Doble de 8 bytes Alto
Doble de 8 bytes Bajo
Doble de 8 bytes Cerrar
1 o 2 bytes int TickVolume
1 o 2 bytes int Spread
y hasta 4 bytes de Volumen
Y la longitud de los dos o tres últimos int's está determinada por el primer Separador, por lo que entendí. No entiendo cómo... ¿Podría decirme cómo determinar que 1 o más bytes serán los últimos 2-3 int?
Una pista, por favor...
Creo que lo he adivinado: el separador contiene una estructura de lectura de datos en código de 16 bytes. Como Separator=18385028, en 16º desde el bit más bajo 4888811, es decir 4 bytes, 8 bytes .... 1 byte.
¿Parece ser este el caso?
P.D. Así es exactamente como se leen los archivos, sólo que hay que saltar 189 bytes entre días.
Ahora entiendo por qué los desarrolladores no hacen públicos estos archivos. No se trata sólo de la sincronización con el servidor, sino que parece que tienen miedo de que se les reproche la estructura y organización de los archivos, como un auténtico "Ay de Wit". Son demasiado baratos para añadir a Aski, pero para todo tipo de reaseguro contra la no sincronía, bueno, hicieron todo un barco atómico "Lenin". Personalmente no entiendo todas estas perversiones y son tristes.
Ahora entiendo por qué los desarrolladores no hacen públicos estos archivos. No se trata sólo de la sincronización con el servidor, sino que parece que tienen miedo de que se les reproche la estructura y organización de los archivos, como un auténtico "Ay de Wit". Son demasiado baratos para añadir a Aski, pero para todo tipo de reaseguro contra la no sincronía, bueno, hicieron todo un barco atómico "Lenin". Personalmente no entiendo y me siento triste por todas estas distorsiones.
Los archivos *.HCC son bloques de datos comprimidos, lo que significa que no son adecuados para su lectura directa.
Estos archivos sirven como datos de entrada para crear plazos de trabajo comprimidos, que se colocan en el subdirectorio /cache.
Los archivos *.HCC son bloques de datos comprimidos, lo que significa que no se pueden leer directamente.
Estos archivos sirven como datos de origen para la creación de los tiempos de trabajo sin comprimir, que se colocan en el subdirectorio /cache.
Renate. ¿Por qué lo hicieron tan complicado? ¿Está justificado? No soy programador y probablemente entienda algo mal, pero mirar el orden de las entradas es simplemente espeluznante. ¿Es conveniente para su propio trabajo?
En realidad, claro, lo estaba mirando para ver si podía sobrescribir los archivos hcc. Pero después de ver su complejidad, no quiero seguir analizándolos. Ahora mismo estoy mirando las cotizaciones de FXCM en demo. Pero por alguna razón, la historia es sólo de octubre. Tengo una cuenta con ellos, pero sin margen de beneficio con comisión. Llevo años utilizando su API para descargar minucias de TS2 y también he utilizado Asks. Quería implementarlos en MT5 para hacer mis pruebas más realistas. Pero ahora no tengo ganas. Si los desarrolladores no nos proporcionan la estructura completa de los archivos hcc tendremos que hacer pruebas en MT4 utilizando scripts que lean datos reales con Askas de los archivos históricos disponibles. Por cierto, FXOpen da el historial con Askas directamente en MT4. Eso es genial. Es una pena que no se puedan utilizar en el probador. Pero al menos se puede probar con scripts.
Intenté mirar los archivos del historial de hcc por el interés.
Resulta que la línea de registro de datos dentro del binario hcc comienza con FileSeek(handle,15333,SEEK_SET)
y qué hay en estos primeros 15333 bytes, ¿podrías averiguarlo?
Creo que lo he adivinado: el separador contiene la estructura de lectura de datos en código de 16 bits. Como Separator=18385028, en 16º desde el bit más bajo 4888811, es decir 4 bytes, 8 bytes .... 1 byte.
¿Parece ser este el caso?
hmm, parece que sí. resulta que el archivo se lee bloque a bloque, variando el tamaño del bloque en función del separador especificado.
P.D. Así es exactamente como se leen los archivos, sólo que entre los días hay que saltarse 189 bytes.
Me he dado cuenta de que los días empiezan realmente con la "cabecera". En el que va el nombre del personaje, etc. Probablemente, este sombrero ofrece información cuantitativa sobre los datos contenidos en este bloque de días.
PS
No abandones el tema, porque es muy interesante crear tus propias actas. A no ser, claro, que el terminal las sobrescriba durante otra sincronización con el servidor.Disponemos de un formato de compresión muy eficaz; sin él, el tráfico en la red sería muchas veces mayor.
Estoy trabajando en Windows que no es ruso, puse el idioma del MetaEditor en ruso, pero cuando llamo a la ayuda (F1), aparece en inglés. Me podéis decir si hay que cambiar algo más al ruso, para que la ayuda aparezca en ruso. Yo uso el Windows ruso en casa y todo va bien.
Y mira en los directorios, ¿tienes un archivo del Manual en ruso allí?
Trabajo en Windows que no es ruso, puse el idioma del MetaEditor en ruso, pero cuando llamo a la ayuda (F1), aparece en inglés. ¿Sabe usted, hay algo más, que debe ser cambiado al ruso, para que la ayuda aparezca en ruso? En casa uso el Windows ruso y todo es normal.
Después de cambiar el idioma en el MetaEditor, ¿lo has reiniciado?
Lo comprobaremos.