Ошибки, баги, вопросы - страница 3593

[Maxim Kuznetsov]

Putnik #:

Попробовал, не помогло.

DL 0 23:51:40.684 TestScript (EURUSD,H4) Date3=1970.01.01 00:00:00

PG 0 23:51:40.684 TestScript (EURUSD,H4) date is 1970.01.01 00:00:00

тогда откройте файл в HEX редакторе и посмотрите первый байт. что там у вас.

потому-что вот тут:

там пробела вроде как не должно быть...может там у вас какой-то служебный символ попался. Может BOM 

и ещё раз: не надо Print...

PrintFormat("Str[0]=<<%s>>",Str[0]); // и будет отчётливо видно, есть там лишние "пустые" символы или нет

[Putnik]

Putnik #:

Не читается дата записанная в файл. Что не так?

Вывод:

LJ 0 12:44:54.122 TestScript (EURUSD,H4) -----

NS 0 12:44:54.122 TestScript (EURUSD,H4) Date1=2024.11.28 09:22:00

QS 0 12:44:54.122 TestScript (EURUSD,H4) Str= 1732785720 2024.11.28 09:22

QQ 0 12:44:54.122 TestScript (EURUSD,H4) Date2=1970.01.01 00:00:00

CL 0 12:44:54.122 TestScript (EURUSD,H4) StrStr[0]= 1732785720 StrStr[1]=2024.11.28 StrStr[2]=09:22

DJ 0 12:44:54.122 TestScript (EURUSD,H4) Date3=1970.01.01 00:00:00

>>>К разработчикам<<<

Кажется нашел проблемное место. Открыл текстовый файл в 16-ричном коде. Обнаружил пару байт, в самом начале файла, 'FF' и 'FE'. Они дают лишний/неизвестный знак к числу '1732785720'. Очевидно, что StringToInteger() возвращает по ошибке "неизвестной цифры" ноль. Поэтому ноль и выводится... 

Интересно, что если убрать строку:

FileSeek(H_File,0,SEEK_SET);

то все начинает работать нормально. Если же принудительно перевести указатель файла на ноль, тогда и происходит ошибка чтения из текстового файла.

PS

Пробовал в МТ4, там без проблем, ни каких лишних байт не пишется.

Пробовал удалить байты "в ручную", после этого файл читается без сбоев.

Пробовал создавать тестовый файл в блокноте и в word, таких байт в начале не обнаружено.

[JRandomTrader]

Putnik #:

>>>К разработчикам<<<

Кажется нашел проблемное место. Открыл текстовый файл в 16-ричном коде. Обнаружил пару байт, в самом начале файла, 'FF' и 'FE'. Они дают лишний/неизвестный знак к числу '1732785720'. Очевидно, что StringToInteger() возвращает по ошибке "неизвестной цифры" ноль. Поэтому ноль и выводится... 

Интересно, что если убрать строку:

то все начинает работать нормально. Если же принудительно перевести указатель файла на ноль, тогда и происходит ошибка чтения из текстового файла.

PS

Пробовал в МТ4, там без проблем, ни каких лишних байт не пишется.

Пробовал удалить байты "в ручную", после этого файл читается без сбоев.

Пробовал создавать тестовый файл в блокноте и в word, таких байт в начале не обнаружено.

Попробуйте при открытии файла добавлять флаг FILE_ANSI.

[Putnik]

JRandomTrader #:

Попробуйте при открытии файла добавлять флаг FILE_ANSI.

FILE_ANSI помогает. Лишних байт нет.

[Putnik]

FILE_ANSI добавлять при записи и при чтении.

На картинке:

Верх) при записи и чтении

Низ) только при записи

[Maxim Kuznetsov]

Putnik #:

 Обнаружил пару байт, в самом начале файла, 'FF' и 'FE'. Они дают лишний/неизвестный знак к числу '1732785720'. 

Это тот самый BOM (https://ru.wikipedia.org/wiki/Маркер_последовательности_байтов)

для уверенности ВСЕГДА задавайте все нужные флаги открытия файла. Не полагайтесь на умолчания.

---

уже привычка, для записи в текстовый файл писать FileOpen(fileName,FILE_WRITE|FILE_SHARE_READ|FILE_TXT|FILE_ANSI,';',CP_UTF8)

"файл для записи, разрешено одновременно чтение, интерпретировать как текст, с однобайтной кодировкой, разделитель полей ';', кодировка utf-8"

а при открытии файла на чтение всегда проверять есть-ли там BOM в начале. Потому что файл может быть чёрти где пересохранён с этим дурацким маркером

[Alexey Viktorov]

Тут слушок прошёл, что в госдуме обсуждали необходимость закрыть цирки. 

Да и пусть закрывают… На форуме почитать и в цирк ходить не надо. ТРИ страницы обсуждение и никто не задался вопросом: А зачем преобразовывать тип datetime в int? Что вы хотите увидеть если 8ми байтный тип перевести в 4х байтный… Зачем строку переводить в int и затем в дату? Почему не перевести строку в дату???

2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        -----
2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        Date1=2024.11.28 09:22:00
2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        Str=1732785720 2024.11.28 09:22
2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        Date2=2024.11.29 00:00:00
2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        StrStr[0]=1732785720 StrStr[1]=2024.11.28 StrStr[2]=09:22
2024.11.29 10:43:07.871 Test shablon (GBPUSD,H1)        Date3=2024.11.29 00:00:00

[Putnik]

Сбой чтения/записи текстового файла решается добавлением флага FILE_ANSI.

[Alexey Viktorov]

Putnik #:
Сбой чтения/записи текстового файла решается добавлением флага FILE_ANSI.

Сбой чтения\записи решается правильным преобразованием данных.

[Maxim Kuznetsov]

Alexey Viktorov #:

Тут слушок прошёл, что в госдуме обсуждали необходимость закрыть цирки. 

Да и пусть закрывают… На форуме почитать и в цирк ходить не надо. ТРИ страницы обсуждение и никто не задался вопросом: А зачем преобразовывать тип datetime в int? Что вы хотите увидеть если 8ми байтный тип перевести в 4х байтный… Зачем строку переводить в int и затем в дату? Почему не перевести строку в дату???

у вас классика утреннего бреда...надо высыпаться :-)

тип datetime и так целое число, 64 бита. И нигде автор в 32 бита его не преобразует.

datetime как целое число преобразуют в строку (IntegerToString(long x,..)) и это число записывают в файл. Потому-что в виде числа оно стандартно и портабельно, это unixtime то есть кол-во секунд с 1970г, а в текстовом представлении MQL оно только в MQL. 

на досуге попробуйте привести штатный datetime в столь-же штатный SQLite datetime.