Любые советы для тех, кто хочет перейти с Delphi 7 (и ниже) на Delphi 2010? - PullRequest
17 голосов
/ 30 апреля 2010

После обновления 4 и 5 мне интересно переоценить Delphi 2010. На этот раз я намереваюсь перенести часть своего кода (в малом масштабе), чтобы увидеть, насколько сложно это сделать в больших масштабах.

Основной проблемой, похоже, является преобразование ASCII в Unicode. Какие-либо советы или ресурсы по этому поводу, которые вы нашли полезными?

Большое спасибо.


Edit:

На данный момент моя рекомендация для других людей (которые хотят обновить) будет:

http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf

Является ли WideString идентичным String в Delphi 2009

Какая версия компилятора для Delphi 2010?

http://chee -yang.blogspot.com / 2008/10 / Дельфи-2009-unicode.html

Обратите внимание, что изображения Gif (от Melander) и Png (от Martijn Saly?) Теперь включены в Delphi 2010. Вам нужно будет использовать условные выражения, чтобы использовать правильную единицу GIF:

USES Windows, SysUtils, Graphics, blabla
{$IFDEF VER150}
  , GIFImage,     {Delphi 7}
{$ELSE}  
  GIFImg          {Delphi 2010}
{$ENDIF}; 

Также вам нужно «исправить» PNG, предоставленный Embarcadero: http://talkdelphi.blogspot.com/2009_03_01_archive.html

Еще одна вещь, которую вам нужно знать, это то, что вам действительно нужно сделать резервную копию вашего проекта, прежде чем открывать его в Delphi 2010. Delphi 2010 изменит ваш файл DFM, даже если вы не нажмете кнопку Сохранить. Форма потеряет данные и не скомпилируется в D7.


ОБНОВЛЕНИЕ

Я наконец обновился. Delphi XE имеет некоторые новые функции. К сожалению, довольно немногие из них вообще не работают (фоновая компиляция, UML-моделирование, понимание кода, например), другие были понижены (помощь и, например). Среда IDE также не такая стабильная и быстрая, как Delphi 7, и на панели инструментов есть реальные проблемы (лучше не настраивайте IDE). Существует также неприятная ошибка, при которой среда IDE использует процессор на 100% (см. Мои другие сообщения обо всех этих проблемах). Я надеюсь, что в обновлениях 2 и 3 они исправят некоторые из наиболее жестких проблем.

В любом случае, я думаю, что я обновил слишком рано, потому что теперь Embarcadero анонсировал 64-битный компилятор, поэтому, вероятно, мне придется заплатить много денег, чтобы перейти на следующую версию Delphi, чтобы получить этот компилятор. Для тех, кто все еще думает перейти на Delphi XE, я бы порекомендовал попробовать Delphi XE перед покупкой, чтобы увидеть, действительно ли он предлагает некоторые функции, которые в противном случае недоступны.

Вывод:

  • Delphi XE содержит множество новых функций, но, очевидно, вы не будете использовать ВСЕ из них.
  • Стабильность IDE не лучше.
  • Он помогает создавать более современные приложения (современный интерфейс открытия / сохранения пользовательского интерфейса, манифест приложения).
  • Поддержка Unicode.

Ответы [ 7 ]

12 голосов
/ 30 апреля 2010

Специально для этой проблемы мы создали веб-страницу:

http://www.embarcadero.com/rad-in-action/migration-upgrade-center

Там вы можете найти веб-страницы, документы, повторы вебинаров и т. Д., Которые охватывают проблему миграции.

Первое, что люди говорят: «У меня огромная база кода, и переход на Unicode займет вечность», и почти без исключения они обнаруживают, что «навсегда» на самом деле гораздо более короткий период времени, чем они думали, и что новый Особенности Delphi 2010 делают все это стоящим.

5 голосов
/ 30 апреля 2010

Самые большие проблемы с сторонними библиотеками и VCL. Если они не на D2010, это может быть больно. Проблема Unicode возникает, если вы выполняете вычисления с длиной строк или массивов PChar, принимая один байт на символ. Обычно вы можете обходиться без проблем, рассматривая все как AnsiString / AnsiChar в старом стиле. Но тогда вы не получите преимущества Unicode. Если у вас нет ничего, что было бы трудно сделать в Юникоде, просто делайте все в Юникоде, и вы будете намного дальше, чем если бы вам приходилось беспокоиться о переключении назад и вперед.

4 голосов
/ 01 мая 2010

Преобразование кода в Unicode само по себе не занимает много времени, если вы не сделали ничего «смешного» со своими строками. Я преобразовал около 1 млн строк кода + базу данных менее чем за 2 недели. Ребята из codegear отлично поработали, сделав это намного проще.

Ваш код может перекомпилироваться в D2010 без каких-либо изменений (но с несколькими тоннами подсказок / предупреждений).

Наихудшая проблема от конвертации - неправильные вызовы API-интерфейса Windows. Например, функция GetComputerName, которая запрашивает размер буфера в TChars (как указано в API). В Ansi TChar = 1 байт, поэтому Length = SizeOf. В Юникоде это больше не так. Хуже того, вызов API может не потерпеть неудачу. Он просто перезапишет некоторую допустимую часть памяти и чуть позже вылетит.

Ох ... И есть еще те небольшие различия между Ansi и Unicode в Windows API. Например, lpCommandLine CreateProcess доступен только для чтения в версии Ansi, но для чтения / записи в версии Unicode. Поэтому использование константы в качестве параметра работало нормально в Ansi, но приводило к сбою в Kernel32.dll в Unicode.

В целом, многое зависит от качества кода, с которым вы работаете. Плохой код может быть очень трудно портировать на D2010. Хороший код должен быть довольно простым.

и прочитайте ресурсы, на которые ссылается Ник Ходжес, они очень полезны.

3 голосов
/ 01 мая 2010

При возникновении проблем с конвертацией в Unicode лучше всего узнать о проблемах, с которыми сталкиваются люди, и о том, что сделали другие, - получить Технический документ Кэри Дженсона: Delphi Unicode Migration для простых смертных .

Также я настоятельно рекомендую «Справочник Delphi 2009» Марко Канту , в котором описываются все изменения в выпуске Major 2009, который включает Unicode, Generics и многое другое. Большая часть его материала Unicode из этой книги находится в его Белой книге: Delphi и Unicode .

2 голосов
/ 01 мая 2010

Мы обновились с Delphi 7 до Delphi 2007, 2009 и 2010! Ниже перечислены самые большие проблемы, которые мы нашли.

  • Потоки изменены, при этом Resume и Suspend не поддерживаются.
  • Unicode
  • Структура проектов изменилась и не имеет обратной совместимости
  • Структура dfms изменилась и не имеет обратной совместимости

Надеюсь, это поможет.

1 голос
/ 05 мая 2010

Я согласен с Крисом - самой большой проблемой при переносе нашего кода в 2010 было то, что все сторонние библиотеки работали. Некоторые из них нуждались в незначительных изменениях исходного кода и должны были быть установлены из измененного источника. Тем не менее, это сказало, что это не было больше чем день или около того, чтобы разобраться с вещами.

Единственная другая проблема, с которой мы столкнулись в 2010 году, заключалась в том, что одна небольшая часть кода стала глючной из-за изменения способа работы ProcessMessages 2010. Это был старый кусок кода, который, вероятно, не следовало писать так, как он был начат (ProcessMessages и Sleep () внутри цикла while, ожидающего изменения переменной OPC). Он работал в 2007 году, но в 2010 году он каким-то образом пожирал системные сообщения и блокировал сервер OPC. Для нас это было небольшое исправление, но, как сказал Кен, это, вероятно, будет зависеть от качества кода, который вы переносите. 2010 кажется немного менее терпимым к плохой практике и уродливым хакерам.

0 голосов
/ 29 марта 2018

Посмотрите этот веб-семинар Embarcadero о том, как перейти с более старых выпусков Delphi, с некоторыми историями о том, что искать и как обновить ваш код (включая инструменты и ресурсы, которые помогут вам в этом), по этой ссылке: https://community.embarcadero.com/blogs/entry/migrating-delphi-case-studies

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...