Что изменилось в 0.9.26? Где мои тексты???

[Troublemaker]

0.9.26/win релиз. Кодировка исходника - 1251. В exe-шнике все нужные тексты видны нормально. Но:

Вот так выглядит проект, собранный в 0.9.24:

lazarus-24-form.jpg

А вот так выглядит он же (исходник не менялся) в 0.9.26:

lazarus-26-form.jpg

Вопрос: почему похерились тексты, которые меняются в рантайме? (тултипы, названия радиокнопок, заголовок окна и т.п.)

Весь в расстройстве...

[Brainenjii]

Надо перевести их в UTF8, вроде ж уже обсуждалось ^_^

[Troublemaker]

Надо перевести их в UTF8, вроде ж уже обсуждалось ^_^

Пробовал... эту фишку я увидел. Но тогда начинаются другие грабли. Например, есть у меня такое:

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

var a:string
...
a:='** что-то там'
...
a[1]:='Б' //заменяю первый символ в строке


И при компиляции ругается: хочу, мол, char, а мне дают ConstantString, то бишь, widechar. Это значит надо будет по всем исходникам менять объявления переменных и подобные присваивания. Проще сразу головой об стену. Или каким-то образом заблокировать перевод "вшитых" текстов в utf. Это возможно? Или плюнуть на 26 и продолжать в 24?

[yantux]

Надо перевести их в UTF8, вроде ж уже обсуждалось ^_^

viewtopic.php?f=5&t=3629&p=26686&hilit=UTF8#p26686

С функцией CP1251ToUtf8() у меня ни как не хочет компилится.

[Mr.Smart]

Надо перевести их в UTF8, вроде ж уже обсуждалось ^_^

Пробовал... эту фишку я увидел. Но тогда начинаются другие грабли. Например, есть у меня такое:

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

var a:string
...
a:='** что-то там'
...
a[1]:='Б' //заменяю первый символ в строке


И при компиляции ругается: хочу, мол, char, а мне дают ConstantString, то бишь, widechar. Это значит надо будет по всем исходникам менять объявления переменных и подобные присваивания. Проще сразу головой об стену. Или каким-то образом заблокировать перевод "вшитых" текстов в utf. Это возможно? Или плюнуть на 26 и продолжать в 24?

в модуле LCLProc есть функции для работы в UTF-8

[Odyssey]

Это значит надо будет по всем исходникам менять объявления переменных и подобные присваивания. Проще сразу головой об стену. Или каким-то образом заблокировать перевод "вшитых" текстов в utf. Это возможно? Или плюнуть на 26 и продолжать в 24?

Насколько я знаю, "отключить" utf-8 в 0.9.26 невозможно, поэтому варианта только 3 (по убыванию трудоемкости):
1) переписать код с использованием функций из LCLProc, и таким образом ввести в приложение полную поддержку Unicode;
2) оставить исходный код в cp1251, вести обработку текста как раньше в cp1251, а при взаимодействии с LCL-контролами перекодировать текст в utf-8;
3) остаться на 0.9.24.

[Troublemaker]

оставить исходный код в cp1251, вести обработку текста как раньше в cp1251, а при взаимодействии с LCL-контролами перекодировать текст в utf-8;

Чувствую, так и придется сделать, а заодно переопределить кучу string-ов. И забыть про использование отладчика, поскольку он не умеет показывать выражения типа utft8toSys(string)

[NXP]

Перевод на UTF-8 это очень хорошая идея.
Теперь не будет проблем при переходе с Win машины на Linux и обратно.
Спасибо разработчикам за этот подарок. Давно надо было это сделать!
Да и с СУБД теперь проще будет

ps Opera на всех платформах использует KIO-8, и ничего

[Mr.Smart]

Спасибо разработчикам за этот подарок.

Присоединяюсь!

[Troublemaker]

Перевод на UTF-8 это очень хорошая идея.

Возможно. Но как быть с сотнями кило исходников, где используется посимвольная выборка из строк? Всё переписывать, менять все структуры данных?
Сейчас внимательно изучаю http://wiki.lazarus.freepascal.org/LCL_Unicode_Support#Instructions_for_users, и как-то грустно становится

[Attid]

Возможно. Но как быть с сотнями кило исходников, где используется посимвольная выборка из строк? Всё переписывать, менять все структуры данных?

ну если сразу сделал грамотно и все делается в вынесеных процедурах то поменять только в одном месте.
если нет то как раз время для рефакторинга =) его как раз полезно через некоторое время делать =)

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

постепенно буду на LCLProc переводить где будет сказываться быстродействие либо будут всплывать ошибки\переделки.

[Odyssey]

И забыть про использование отладчика, поскольку он не умеет показывать выражения типа utft8toSys(string)

Здесь поможет консоль, достаточно создать маленький отладочный модуль с функцией типа Utf8DbgOut(const aMessage: string) которая будет перекодировать строку из utf-8 (а под windows еще и делать CharToOEM) и выводить сообщение в консоль. При желании можно элементарно переключиться на ведение лог-файла отладки. При создании релиза этот модуль убирается из uses, и забытые отладочные вызовы подсвечиваются как ошибки, что помогает от них избавиться.

[B4rr4cuda]

Возможно. Но как быть с сотнями кило исходников, где используется посимвольная выборка из строк? Всё переписывать, менять все структуры данных?

Это можно вылечить заменой string на widestring. Дешево и сердито.

[VirtUX]

Спасибо разработчикам за этот подарок.

Присоединяюсь!

+1

[Troublemaker]

достаточно создать маленький отладочный модуль

ТОгда возникает сильное сомнение в необходимости окна Debugger Watches, раз единственное, что оно может показывать, это изменения глобальных переменных

Я не знаю, какую переменную или результат какой функции мне понадобится посмотреть в тот или иной момент отладки. А делать полный дамп всех переменных после каждой команды, это как-то некрасиво

заменой string на widestring. Дешево и сердито.

Я уже думал об этом. Но это приведет к удвоению всех выходных данных (у меня используются StringList-ы в .ini-формате, по ряду причин всевозможные встроенные БД не подходят, формат обсуждению и изменению не подлежит) и необходимости писать конвертер. Хотя здесь тоже не совсем понятно - как именно работает strings.LoadFromFile, в какой кодировке идет чтение запись.