GunSmoker,

В Button - да, в этом случае всё нормально отображается.
А если задать "Пёсик" в Edit (в свойствах формы) - тогда Edit отображается с крякозябрами.
Как оказывается, там 6 символов вместо 5. Если записать значение Edit.Text в файл - то файл будет 6 байт, при открытии в FAR в кодировке 65001 покажет "Пёс".

В свойствах на форме задаём (Delphi 7):

Edit1.Text = Пёсик

object Edit1: TEdit
Left = 8
Top = 16
Width = 121
Height = 21
TabOrder = 0
Text = #1055#1105#1089#1080#1082
end

Далее запускаем программу, в FormActivate выполняем

System.Assign(f, 'c:\temp\15.txt');
System.Rewrite(f);
System.Write(f, Edit1.Text);
System.Close(f);

каким-то магическим образом в 15.txt оказывается 6 символов вместо 5:

#208 #159 #209 #145 #209 #129

Если в FAR установить кодировку UTF-8 то будет

Пёс

Но вопрос этот решаемый. Как я понимаю - надо перекодировать значение до вызова OnActivate тогда всё будет нормально, без потери данных.

GunSmoker,

ShowMessage('Песик');

- ну тут как раз всё просто - перекодируем в UTF-8 и выводим. Переписывать код не придется - достаточно в конце секции USES подключить свой модуль с правильным ShowMessage - который перекодирует данные перед выводом. Или отказываемся от ShowMessage, используем MessageBoxW.

Dimitry Sibiryakov,

Такое поведение - вообще если создать новый чистый проект без каких либо перехватчиков. С Button всё нормально как и пишет GunSmoker. А с Edit как-то по-другому получается, значение портится, вместо 5 байт получается 6 и "Пёсик" обрезается до "Пёс" - правда, становится 6 байт вместо 5.

GunSmoker,

>Я вот из личного опыта скажу: перейти на Unicode это в несколько раз проще, чем расставлять везде костыли.

Да - правильнее всего, конечно, будет перейтти на D2010. Но и в пользу костылей есть некоторые аргументы.

К счастью, не у всех пользователей включена по умолчанию опция

"Бета-версия: Использовать Юникод (UTC-8) для поддержки языка во всем мире"

поэтому вставка костылей не повлияет на стабильность работы отлаженного ПО у 90% пользователей - у кого эта опция по умолчанию отключена ничего не изменится и всё останется как было. А у тех, у кого опция включена - да, будут ловить баги (но постепенно, с расстановкой костылей количество багов будет уменьшаться).

А вот при переходе на Delphi 2010 изменения затронут сразу 100% пользователей. И придется вести две версии - стабильную на D7 и тестовую на D2010. Поэтому и пугает так переход на D2010.

Хотя я понимаю, что это всё равно неизбежно - и чем дальше тем труднее будет перейти, тк количество кода, хаков и прочего в программе растёт, а у D7 и так понятно, что нет будущего (например, опасаюсь, что рано или поздно Microsoft вообще откажется от поддержки 32-битного кода как недавно сделала Apple и это поставит окончательную точку в использовании D7). Всякие TntComponents использовать не хочется - т. к. опасаюсь, что это ещё больше затруднит слезание с D7 в будущем.

Поэтому, наверное, расставить временно костыли и готовить проект к переходу на D2010 раз уже такие сложности с переходом сразу на XE8/XE10. Надеюсь, D2010 - правильный выбор - т. к. это наиболее ранняя из версий с поддержкой Unicode и разницы с D7 у неё должно быть меньше, чем в случае скажем с XE2, XE8 или XE10. Есть, конечно еще D2009 - но судя по всему, D2010 это та же 2009 только меньше глюков.

А вы не знаете случайно - как запретить компилятору в редакторе кода портить секцию USES? Если в начале каждого модуля формы уже прописано

USES {$I AllVcl.pas}
а в файле AllVcl.pas - список всех модулей, которые могут потребоваться и незачем туда что-то добавлять

но при сохранении и при запуске программы D2010 (кстати, XE2 и XE8 тоже эти страдают) зачем-то добавляет
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs;

и получается каша вида

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs;
USES {$I AllVcl.pas}

которая разумеется, не компилируется. D7 так не делает - а при разработке проекта не задумывалась что потом такие проблемы с переходом на новые версии Delphi возникнут. Неужели в новых версиях Delphi нельзя делать USES сразу всех нужных модулей, подгружая список из файла, а необходимо через запятую перечислять в USES каждого модуля? Но ведь там 10 строк в списке модулей может быть и это очень неудобно - например, если потребуется какой-либо модуль добавить в USES сразу всех форм программы ...

Боюсь, что сделают рано или поздно. Более того, могут подобно Apple вообще отказаться от поддержки 32-разрядного кода. Как подумаю об этом, холодный пот пробирает ...

Так проблема в том, что среда добавляет требуху - но не всё, что у меня прописано в AllVcl.pas, а только ту требуху, которую захочет, в зависимости от того, какие компоненты на данной форме. А в у меня AllVcl.pas прописаны все модули VCL, которые могут потребоваться (а еще IB.pas, shellapi.pas, ComObj.pas и прочее).

И после AllVcl.pas у меня следом идёт MyUnits.pas - то есть

USES {$I AllVcl.pas}, {$I MyUnits.pas};

в котором перечислены мои модули - функционал которых во многом базируется на AllVcl.pas. И если вместо AllVcl.pas использовать требуху, которую вставляет Delphi - мои модули перестанут работать - если Delphi вставит не всё, что нужно - а он как правило вставит не всё - а только то, что ему нужно. И ещё ситуация - если в AllVcl.pas надо будет добавить новый модуль - это делается простой правкой файла AllVcl.pas - а не надо будет лазить по всем модулям и добавлять.

Проблема в том, что если разрешить вставлять Delphi требуху - вроде

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs;

а потом дописывать чтобы было

uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, {$I AllVcl.pas}, {$I MyUnits.pas};

то при компиляции Delphi будет ругаться identifier redeclared. То есть требуха, которую добавляет Delphi - пересекается с той, что у меня в AllVcl.pas, а AllVcl.pas убирать нельзя, так как на нем базируется MyUnits.pas. В этом и проблема. Если бы D2010 не трогал секцию USES как D7 всё было бы нормально.

На 2010 в комплекте есть исходники VCL? Очень нужно чтобы перенести костыли с 7 на 2010. У меня в комплекте с 2010 только dcu. Подозреваю, Embarcadero в 2010 закрыла исходный код VCL, распространяя только DCU. В XE2, XE8, XE10 - кстати исходники есть, как и в 7. А вот в 2010 нет. Вот теперь и думаю, или это целенаправленная политика Embarcadero в 2010 (от которой они потом отказались) или это просто у меня кривая 2010.

Хочется именно 2010, а не XE2 - чтобы изменения были минимальными, а в XE2 уже добавились новые фишки в сравнении с 2010 - вроде USES Vcl.Classes вместо USES Classes и прочее - что создаст дополнительный геморрой при переходе - а переход на Unicode сам по себе уже и так не сахар зачем еще дополнительный геморрой. А уж потом - обжившись на 2010 - переходить сразу на XE10.

[quot GunSmoker#22305639]

Не так уж и много костылей получается. Т. к. в конце каждого модуля у меня подключен список моих модулей

{$I MyUnits.pas}

Там можно и прописать новый вариант ShowMessage и прочего, что перекроет стандартные методы.
Это удобно с одной стороны - а с другой стороны - мешает переходу на новые версии Delphi.

[quot avp_#22305894]

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

Был соблазн сделать, чтобы программа просто меняла системные настройки как нужно и потом перезагружала компьютер - но в этом случае опасаюсь, что программа по поведению будет похожа на вредоносную и соответственно, имеет шанс попасть в базы антивирусов. И вообще это выглядит как серпом по одному месту.

Сейчас занимаюсь подготовкой костылей - чтобы всё приемлемо пусть хотя бы и с некоторыми багами (а не как сейчас - сплошные крякозябры и невозможность работы) работало и при включенной опции "Бета-версия: Использовать Юникод (UTC-8) для поддержки языка во всем мире" на случай если пользователь откажется что-то менять.

И разумеется, хочу перейти на Delphi 2010. Но вот мои USES {$I AllVcl.pas}, {$I MyUnits.pas}; в каждом модуле очень этому мешают.

Ну да - могут сделать какие-нибудь пакости - например, сделать чтобы по умолчанию работали только 64-разрядные программы. А для возможности работы 32-разрядных чтобы было необходимо включить какую-нибудь хитрую галочку в недрах системы и перезагрузить компьютер, разумеется.

Впрочем, с переходом на юникодную версию Delphi подобные пакости будут не страшны. Тк с юникодной 2010 перейти хотя бы на XE2 (минимальная что поддерживает 64-бит) думаю не составит большого труда. Главное уйти с неюникодного D7.