Перенос старого кода Delphi 7 в Delphi XE — юникод действительно нужен?

#delphi #delphi-7 #delphi-xe

#delphi #delphi-7 #delphi-xe

Вопрос:

У меня есть старое приложение, работающее под управлением BDE под управлением Delphi 7, и теперь я купил Delphi XE. Я вижу, что многие люди говорят, что основная проблема переноса кода заключается в переходе на unicode. И, возможно, база данных, поддерживающая unicode.

Но действительно ли мне нужно это делать? Разве я не могу просто придерживаться BDE и какого-нибудь «старого доброго строкового формата»?

Я надеюсь быстро перейти на Delphi Xe здесь, не обязательно используя все новые функции и т. Д. И т. Д….

Rgds PM

Комментарии:

1. Да, просто замените все: String -> AnsiString и Char -> AnsiChar , и вы (вероятно) закончили. Вам также может потребоваться добавить A к функциям Win API, например, DrawTextA вместо DrawText .

2. @Andreas, это было бы самоубийством IMO; в этом случае я бы позволил Windows.pas вместо этого связать правильную версию.

3. Прочитайте эту статью Марко Канту, в ней рассматриваются большинство вещей, которые следует учитывать при уникодировании приложений. Delphi и Unicode . И google для Ника Ходжеса и Unicode, чтобы прочитать его блоги на ту же тему.

Ответ №1:

Поля данных, которые связывают ваши данные с базой данных, не изменились. TStringField по-прежнему имеет свойство Value типа AnsiString, которое соответствует старому поведению.

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

Кроме того, я предлагаю заменить BDE более современным решением в обозримом будущем — не только из-за Unicode.

Комментарии:

1. BDE не переносится на 64-разрядную Windows, и если Embarcadero продолжит поставлять 32-разрядную BDE за пределы XE2, я буду раздражен на них. Выйдите из BDE. Он мертв.

Ответ №2:

Довольно сложно избежать использования нового UnicodeString , которому string теперь присвоен псевдоним. Вы можете написать весь свой код с AnsiString помощью, если хотите, но зачем беспокоиться? Как только вы используете любую нетривиальную библиотеку (например, RTL, VCL, стороннюю), вы плывете против течения. Если вы попытаетесь продолжить, AnsiString вы, на мой взгляд, на самом деле усложните себе жизнь.

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

Комментарии:

1. Действительно, во многих (возможно, в большинстве) случаев вам не нужно ничего изменять в своем коде.

2. Хммм …. два разных представления ….. Дэвид: Не уверен насчет этой части «плавание против течения»…. с какими проблемами я, вероятно, столкнусь с исправлением AnsiString при использовании VCL?

3. Андреас: Вы имеете в виду даже не переход на AnsiString? Но как насчет моей базы данных BDE ….. что мне, вероятно, придется там делать, чтобы продолжать ее использовать?

4. @Petter Вы можете написать весь свой код, используя AnsiString . Это просто то, что происходит на границах между вашим кодом и всеми другими библиотеками, которые вы используете. В основном вам ничего не нужно делать, чтобы перейти на Unicode. Вы просто перекомпилируете.

5. Windows — это юникод. Интернет — это юникод. Используйте ansistring во ВСЕМ вашем коде. Это прекрасно. Но windows и интернет никуда не денутся.

Ответ №3:

Я сделал тот же ход с D7 на XE, и это изменение было убийственным. Мое приложение, как и ваше, включает в себя базу данных — в моем случае ее компоненты Interbase и Interbase Express, которые являются частью Delphi. Я принял решение перейти на Юникод, но это было некрасиво.

Я читал статьи, но по сравнению с моим опытом они казались неполными или, возможно, даже неправильными по некоторым пунктам. Я думаю, что статьи написаны с точки зрения приложения Delphi без базы данных. Я полагаю, что были критические ошибки в Interbase Express (Delphi) и в Interbase. Я думаю, что по крайней мере одна ошибка была исправлена в IB и пара в Delphi — если вы перейдете на версию XE. (Я не хочу думать о том, чтобы снова пройти через это прямо сейчас).

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

Противоречивые мнения, выраженные в этой теме, указывают на путаницу с Юникодом. По некоторым из этих проблем я не знаю, как это будет работать, даже пройдя через это. Но у меня есть сомнения в том, что я вообще смогу пройти через это и удержать BDE. Это вполне может иметь встроенные проблемы, которые не будут исправлены, и с которыми вы не можете справиться. В QC есть несколько записей, которые вы можете проверить, чтобы увидеть некоторые нерешенные проблемы.

Когда мое приложение было в D7, моя база данных IB была ansi. При первом преобразовании в Delpi XE, казалось, все работало нормально, хотя это была лишь краткая проверка. IB поддерживает Unicode, и я преобразовал туда свои данные. Вы бы / не могли бы вы сделать это со своими данными? Только после этого я обнаружил проблемы. Я думаю, что любое значимое преобразование в Unicode означает, что вы сначала конвертируете свое хранилище данных в Unicode, а затем ваше приложение Delphi.

Итак, после всего этого, почему вы переходите на XE, если вам не нужен unicode? Это просто для обновления или есть что-то, чего вы пытаетесь достичь? Я надеюсь, что этот длинный пост поможет.

Ответ №4:

У нас также есть много приложений, работающих под управлением BDE с Delphi-7, и мы рассматриваем возможность перехода на DelphiXE. Переход не из приятных … если вы хотите, чтобы ваша программа работала в 64-разрядной версии Windows7, вам нужно будет преобразовать BDE или загрузить BDE express или другой инструмент. У BDE проблемы с утечкой памяти, поэтому мы преобразовали эти компоненты, но останемся в Delphi-7 для старых продуктов и будем использовать Delphi XE для новых проектов. Желаю удачи.