Портирование приложения Delphi 2006 на XE

Я хочу перенести несколько крупных приложений с Delphi 2006 на XE. Причины не столько в Unicode, сколько в (надеюсь) лучшей стабильности IDE, поддержке встроенного PNG, большем количестве компонентов, меньшем количестве ошибок VCL, меньшей зависимости от сторонних материалов, меньшем количестве ребят от вас и т.д. приложений может извлечь выгоду из Unicode, но это не проблема в настоящее время. На данный момент я просто хочу пойти по самому прямому пути, чтобы заставить их снова скомпилироваться.

Для начала я изменил все неоднозначные строковые объявления, то есть string на AnsiString или ShortString, char на AnsiChar и pChar на pAnsiChar и перекомпилировал с D2006. Все идет нормально. Ничего не сломалось.

Мой вопрос: где отсюда? Предполагая, что я просто представляю свои исходники компилятору XE и освещаю сенсорную бумагу, что может быть большой проблемой?

Например,

var
    S : AnsiString ; 
...
MainForm.Caption := S ;

Это сгенерирует ошибку? Предупреждение? Я предполагаю, что VCL теперь является Unicode, или XE вытянет компонент, не являющийся Unicode, или преобразует строку? Действительно ли возможно сохранить приложение, использующее 8-битные строки в XE, или будет слишком много головной боли?

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

Еще одна вещь, которая меня интересует, это сторонние вещи. Я думаю, мне нужно будет получить обновленные версии, совместимые с XE.

Любой (положительный!) Комментарий приветствуется.

Источник

2 ответа

Решение

VCL теперь полностью Unicode, поэтому код, который вы показали, будет генерировать предупреждение компилятора, а не ошибку о неявном преобразовании из AnsiString в UnicodeString, Это потенциально конверсия с потерями, если AnsiString содержит символы не ASCII (которые компилятор не может проверить). Если вы продолжаете использовать AnsiString, тогда вы должны сделать явное приведение типа, чтобы избежать предупреждения:

var
  S : AnsiString ; 
...
MainForm.Caption := String(S);

Лучше всего, если вы не Ansi-fying ваш код, как это. Embrace Unicode. Ваш код будет легче управлять им, и он будет более переносимым для будущих версий и платформ. Вы должны ограничить AnsiString использование только в тех местах, где на самом деле нужен Ansi - сетевые коммуникации, файловый ввод / вывод устаревших данных и т. д. Если вы хотите сэкономить память внутри своего приложения, особенно если вы используете только символы ASCII, используйте UTF8String вместо AnsiString, UTF-8- это 8-битная кодировка Unicode и преобразования между UTF8String а также UnicodeString без потерь без предупреждений компилятора.

Источник

Это длинный прыжок с 2006 по 2011 год

Но это возможно, если учесть, что:

  • Вы должны конвертировать строковые переменные, используя новые методы преобразования;
  • Вы должны проверить все версии между 2006 и xe, чтобы знать, как изменились библиотеки, потому что некоторые были spplited, другие объединены, а некоторые удалены;
  • Вы должны купить / загрузить обновление (если есть) ваших сторонних компонентов.
Источник
Другие вопросы по тегам