Перешёл с 0.9.30на 1.4 - проект не работает. Опять юникод???

[postscripter]

Привет! Был проект под Lazarus 0.9, при переходе на 1.4.2 перестал работать. Пример:

Код: Выделить всё

var folder:string;

 folder:=ExtractFilePath(application.ExeName); 
 try
  if fileexists(folder+'123.txt') then memo1.Lines.LoadFromFile(folder+'123.txt');
 except
  Showmessage(SysErrorMessage(GetLastError));
 end;  

1) Отладчик показывает, что folder='c:\????????\'.
2) Fileexists выдаёт TRUE.
3) Затем перехватывается исключение "Unable to load file C:\Русский\123.txt". (без try его будет видно)
4) Затем ShowMessage показывает текст ошибки: '???? ?? ???? ??? ? ? ????? [Ok]'

В начале модулей и в опциях сборки обнаружил {$H+}, но он ни на что не влияет. Где ещё ковырять? Повторюсь, этот код работал раньше (правда, насчёт GetLastError не уверен).

NeedRTLAnsi выдаёт True. Замечательно, моя windows не поддерживает юникодные api?

[Ism]

FileExists работает в кодировке оси, в Windows это cp1251,
LoadFromFile же скорей всего берет в utf8

[postscripter]

Понятно, почему это происходит. Непонятно, что делать, и как оно работало до этого. Что именили в Лазарусе.

Можно конечно пройтись автозаменой FileExists->FileExistsUTF8, но кроме него там тьма других функций, и хз какие из них теперь не работают.

[Ism]

Работайте только в utf8 даже если для этого нужно явно преобразовывать

[postscripter]

Работайте только в utf8 даже если для этого нужно явно преобразовывать

Что для этого нужно менять? Проект большой.

Сейчас происходит следующее:
1) Тип string равносилен ansistring благодаря {H+}.
2) Переменная folder получает ansi-значение, потому что цепочка вызовов extractfilepath(...) в конце обращается к shortstring функции system.ParamStr.
3) Вызов FileExists отрабатывает корректно, потому что ожидает анси-строку и ссылается на неюникодную версию WINAPI без -w. Кстати, почему?
4) Далее. Вызов LoadFromFile в exe-шнике, откомпилированном версией 0.9.30, приводит к созданию объекта типа TFILESTREAM.
4.1) В новой версии Лазаруса создаётся объект TFILESTREAMUTF8, который принимает на вход нашу ansi-строку Folder и обламывается.

Они поменяли внутреннюю логику работы некоторых базовых классов. Где найти список, и что теперь должен поменять я?

Безымянный 1.png

На скриншоте - как работает старая версия.

Добавлено спустя 1 час 11 минут 2 секунды:
Может быть, моя IDE скомпилирована с ключом -dEnableUTF8RTL? Правильно я понимаю, что когда FPC 2.7.1 с поддержкой этого ключа войдёт в состав IDE, проблема разрешится сама собой, и все системные вызовы API будут -w? А до этого момента - костылить с AnsiToUTF8 или отсиживаться на 0.9?

Добавлено спустя 37 минут 38 секунд:
К сожалению. мат на форуме запрещён. Поэтому вот вам картинка.



А что бы вы сделали с разработчиками, у которых
TMemo.Lines.SaveToFile() требует юникода, а TStringList.SaveToFile() требует ANSI?

Я начинаю понимать, кажется, за что страдал Лазарь.

[resident]

при переходе на 1.4.2 перестал работать

Такое и на 1.2.6 не будет работать.

Где ещё ковырять?

Пробовать UTF8ToAnsi и AnsiToUTF8 в каждом неработающем варианте.

А что бы вы сделали с разработчиками

Идёт бракоразводный процесс.
Судья спрашивает бабу: - Почему разводитесь?
- Он меня сексуально не удовлетворяет.
Судья обращается к мужику: - Вы почему не исполняете супружеский долг?
Встаёт, качаясь от голода, худой и бледный муж и дрожащим голосом произносит.
- Граждане судьи налейте мне тарелку супа и я тут весь зал переебу.

[postscripter]

налейте мне тарелку супа и я тут весь зал

Не знаю как зал, а я с ним реально зае*лся Это где видано, чтобы два экземпляра одного класса TStringList работали по-разному? Как вообще?? Такое только в DelphiXE стало возможно через класс-хелперы.

Байку возьму на вооружение

[hinst]

достали тупые вопросы про кодировки. всем кто не понимает кодировки и их смысл - идти и учить

[postscripter]

достали тупые вопросы про кодировки. всем кто не понимает кодировки и их смысл - идти и учить

Проблема решена, спасибо.

[slyubez]

В самом деле, с кодировками в Лазаре тягомотина. Тоже затрахался, разрабатывая и особенно отлаживая код. Есть большой опыт работы в Дельфи, как в старых, так и в новых, Юникоднутых - там никаких проблем не испытывал. Но в Лазаре, когда одним функциям подавай ANSI, другим - UTF8, и не всегда понятно, когда что использовать, просто бардак.

[qivi]

>>когда одним функциям подавай ANSI, другим - UTF8
+ на сколько я понял FPC начиная с долгожданного 3.0 будет Unicode (UTF-16), то биш нужно будет балансировать между 3 кодировками )))

[Лекс Айрин]

Но в Лазаре, когда одним функциям подавай ANSI, другим - UTF8, и не всегда понятно, когда что использовать, просто бардак

В самой операционке тоже так. Существует, к тому же, дублирование части ANSI и UTF8 функций.

[slyubez]

В самой операционке тоже так. Существует, к тому же, дублирование части ANSI и UTF8 функций.

Это в Линуксе-то?

[Ism]

Тоже затрахался, разрабатывая и особенно отлаживая код. Есть большой опыт работы в Дельфи, как в старых, так и в новых,

Потому, что в Delphi одна кодировка - виндовская

[postscripter]

на сколько я понял FPC начиная с долгожданного 3.0 будет Unicode (UTF-16)

Так вроде с 2.7.1 уже обещают сделать всё хорошо. Системные вызовы будут unicode, внутренняя кухня (RTL) тоже.