All Projects SAS.Планета Домен, сайт, форум, багтрекер Доработка карты (ZMP) Переводы и локализации Прочее

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002166SAS.ПланетаХотелка / Feature requestpublic16-09-2013 06:5626-11-2016 09:41
Reportervdemidov Assigned Tozed  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version121010 
Target Version160707Fixed in Version160707 
Summary0002166: Переход на версию Delphi с полной поддержкой юникода
DescriptionСейчас для сборки как основная используется Delphi 2007. Но только начиная с Delphi 2009 был полный переход на юникод. Для полной поддержки юникода в программе нужно перейти на что-то более свежее.
Tagsюникод

Relationships

parent of 0002169 resolvedvdemidov Исправить импорт plt под юникодной Delphi 
parent of 0002493 resolvedvdemidov Упорядочить использование RegExpr и RegExprUtils 
parent of 0002690 resolvedvdemidov Добавить определение кодировки ini-файлов при загрузке в ConfigDataProvider 
parent of 0002691 resolvedzed Юникодная версия. Результаты геокодера Яндекса в виде знаков вопроса. 
parent of 0002705 resolvedvdemidov Unicode. В юникодной версии экспор в AUX неправильно записывает файл 
parent of 0002781 resolvedGunSmoker Access Violation в TDownloadResultError.GetErrorText в юникодной версии 
parent of 0002868 resolvedvdemidov В юникодной версии SAS, в главном меню, вместо хинтов выводятся знаки вопроса 
parent of 0002869 resolvedvdemidov Проблемы с отображением датчиков в юникодной версии 
parent of 0002877 resolvedvdemidov Поддержка utf-8 и utf-16 при загрузке параметров карты в неюникодной версии программы 
parent of 0002880 resolvedzed Возможно есть проблемы в экспорте в Ecw c использовании PChar в юникодной версии 
parent of 0002881 resolvedvdemidov Проблемы при работе с PChar в юникодной версии в CPDrv.pas 
parent of 0002882 resolvedvdemidov Мелкие проблемы работы с юникодом в MD5.pas и KAZip.pas 
parent of 0002883 resolvedzed Проблемы с юникодом при обработке событий WMCopyData 
parent of 0002047 resolvedvdemidov После изменения названия карты в zmp не меняется название в интерфейсе 
parent of 0002891 resolvedvdemidov Заменить использование WideString 
parent of 0002892 resolvedvdemidov Добавить обработку vtUnicodeString в FinalizeVarRec 
parent of 0002901 resolvedzed Переход на базу меток в SQLite по умолчанию 
parent of 0002975 resolvedzed В Unicode версии неправильно отображаются названия квадратов ГШ 
has duplicate 0002553 closedvdemidov Перевод на рельсы Delphi XE7 
related to 0002107 resolvedzed sml файлы не по стандарту XML 
related to 0002900 resolvedvdemidov Принудительное сохранение ini файлов в utf-8 
related to 0003155 resolvedzed Ошибка в заголовках файлов, экспортированных в формат МЯК (версия 3) 
child of 0000626 resolvedzed Добавить возможность создавать метки и категории в Юникоде 
child of 0000181 resolvedvdemidov Комментарии слоя wikimapia, написанные иероглифами, отображаются знаками вопроса 
child of 0002278 resolvedvdemidov Не импортируется файл с именем с символами не из основной локали 

Activities

vasketsov

16-09-2013 16:34

manager   ~0012805

XE2 или XE4?

vdemidov

16-09-2013 17:05

manager   ~0012806

Да хоть XE5. У меня XE2 установлена. А какую Zed на сервер для сборки поставит та и будет, я не думаю, что там принципиальная разница будет.

vasketsov

16-09-2013 17:12

manager   ~0012808

Под XE4 проект не собирается капитально, юниты надо именовать с префиксами. Если нет желания перелопачивать всё и вся - значит XE2.

vdemidov

16-09-2013 17:16

manager   ~0012809

Ну тебе виднее. Я не пробовал. Но переход на юникод нужен однозначно.

vasketsov

16-09-2013 17:27

manager   ~0012812

Я ставил XE4 чтобы оттуда свистнуть файлы для Sensor API (и ещё несколько зависимых, которых в XE2 нет). Но даже после правки имён юнитов просто так их заюзать в XE2 не вышло из-за delayed. Сделал вывод, что переход 2007 -> XEn для n>2 слишком сложен для одновременной поддержки обоих компиляторов.
Возможно где-то конечно и недодумал.
Также для GR32 (или чего-то такого столь же важного) нет поддержки XE4.

zed

04-09-2014 06:00

manager   ~0014605

Открыл для себя фреймворк Synops mORMot. По поводу работы со строками, в нём заложена идея вообще отказаться от типа string (который в разных версия Delphi, разный), а использовать свой переопределённый тип и внутри фреймворка работать только с utf-8 строками (у них этот тип строк назван RawUTF8), чтобы независимо от версии Delphi была однотипная работа со строками. Соответственно, они переписали SysUtils и всё что касается работы со строками, плюс хорошенько оптимизировали полученный код. Всё это дело живёт в ОЧЕНЬ большом юните SynCommons.pas.

Из описания:

Our mORMot Framework has 100% UNICODE compatibility, that is compilation under Delphi 2009 and up (including latest XE6 revision). The code has been deeply rewritten and tested, in order to provide compatibility with the String=UnicodeString paradigm of these compilers. But the code will also handle safely Unicode for older versions, i.e. from Delphi 6 up to Delphi 2007.

Since our framework is natively UTF-8 (this is the better character encoding for fast JSON streaming/parsing and it is natively supported by the SQLite3 engine), we had to establish a secure way our framework used strings, in order to handle all versions of Delphi (even pre-Unicode versions, especially the Delphi 7 version we like so much), and provide compatibility with the FreePascal Compiler.

Some string types have been defined, and used in the code for best cross-compiler efficiency (avoiding most conversion between formats):
- RawUTF8 is used for every internal data usage, since both SQLite3 and JSON do expect UTF-8 encoding;
- WinAnsiString where WinAnsi-encoded AnsiString (code page 1252) are needed;
- Generic string for i18n (e.g. in unit mORMoti18n), i.e. text ready to be used within the VCL, as either AnsiString (for Delphi 2 to 2007) or UnicodeString (for Delphi 2009 and later);
- RawUnicode in some technical places (e.g. direct Win32 *W() API call in Delphi 7) - note: this type is NOT compatible with Delphi 2009 and later UnicodeString;
- RawByteString for byte storage (e.g. for FileFromString() function);
- SynUnicode is the fastest available Unicode native string type, depending on the compiler used (i.e. WideString before Delphi 2009, and UnicodeString since);
- Some special conversion functions to be used for Delphi 2009+ UnicodeString (defined inside {$ifdef UNICODE}...{$endif} blocks);
- Never use AnsiString directly, but one of the types above.

User Interface layer that you may convert explicitly the RawUTF8 content into the generic VCL string type, using either the Language. UTF8ToString method (from mORMoti18n.pas unit) or the following function from SynCommons.pas:

/// convert any UTF-8 encoded String into a generic VCL Text
// - it's prefered to use TLanguageFile.UTF8ToString() in mORMoti18n.pas,
// which will handle full i18n of your application
// - it will work as is with Delphi 2009+ (direct unicode conversion)
// - under older version of Delphi (no unicode), it will use the
// current RTL codepage, as with WideString conversion (but without slow
// WideString usage)
function UTF8ToString(const Text: RawUTF8): string;

Of course, the StringToUTF8 method or function are available to send back some text to the ORM layer.

A lot of dedicated conversion functions (including to/from numerical values) are included in SynCommons.pas. Those were optimized for speed and multi -thread capabilities, and to avoid implicit conversions involving a temporary string variable.

Warning during the compilation process are not allowed, especially under Unicode version of Delphi (e.g. Delphi 2010): all string conversion from the types above are made explicit ly in the framework's code, to avoid any unattended data loss.

vdemidov

04-09-2014 18:24

manager   ~0014608

Ну так давай, хотя, это несколько расходится с моими мыслями о переходе везде на 2-х байтный юникод, что бы потом в интерфейсах использовать WideString с меньшими расходами, но это такое отдаленное будущее, что бог с ним...
Мне честно говоря очень не хватает новых плюшек делфи.

zed

04-09-2014 19:13

manager   ~0014609

>использовать WideString
Это тип строк работает убийственно медленно. Их вообще не стоит использовать без острой необходимости. Лучше старый добрый PAnsiChar, через который и utf-8 прекрасно передаётся.

vdemidov

04-09-2014 20:37

manager   ~0014610

> Это тип строк работает убийственно медленно.
За все нужно платить. Зато эти строки можно передавать в dll на любом языке скомпилированную в любом компиляторе и обратно без малейших проблем. А это для интерфейсов достаточно важно.

Но я же говорю, что это не существенно и не предлагаю так делать.

И вообще я за скорейший переход на более свежую версию делфи.

vdemidov

20-04-2015 07:21

manager   ~0015615

Какие у нас остались проблемы с переходом на юникодную версию делфи кроме регекспов?

zed

20-04-2015 07:54

manager   ~0015616

А что с регэкспами? Там же widestrig под юникодом. Медленно, но надежно.

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

vasketsov

20-04-2015 12:59

manager   ~0015617

А парсеры и читалки уже умеют отличать буфер и файл с диска соответственно, юникодный он или нет?
А сохранять файлы всегда в юникоде будете?

vdemidov

20-04-2015 13:54

manager   ~0015619

Об этом и вопрос. В большинстве мест там уже есть определение типа текстовых файлов. Но везде ли оно правильно сделано?

vasketsov

20-04-2015 14:33

manager   ~0015620

>В большинстве мест там уже есть определение типа текстовых файлов
Хм. Видимо мы друг друга не очень понимаем. Но мне кажется, что про большинство мест ты несколько погорячился.

Возьмём для примера файл mp (польский формат).
Он может быть не юникодный, но в заголовке указана кодировка.
Я не помню такого куска кода, который бы это нюхал и конвертировал в юникод или текущую кодировку, а без этого что-то искать в общем случае бессмысленно.
И в принципе я поднимал вопрос с определением того, вот конкретно взятый буфер с текстом юникодный или нет, интереса оно у вас не вызвало. А между тем это первое, что надо делать после чтения любого файла, если мы хотим с ним работать как с текстом. У меня есть такой пример в коде внутреннего httpd.

Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?

Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.

У HashFunction есть расчёт хэша по WideString? Нет. А между тем, где оно будет форсироваться после проверки, оно должно быть.

Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
В принципе по каждому сохраняемому типу файлов надо понимать, в каком виде надо уметь их сохранять. Потому что если потом встать в позу, что мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая. Это касается привязок, экспортов и т.п. Даже там, где нет юникода, может прокатить AnsiString и прямое указние кодировки, но перекодировка обязана возникнуть, а сейчас её нет.

Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.

Это только то что я помню сходу. Но даже этого достаточно.

vdemidov

20-04-2015 14:54

manager   ~0015622

>Возьмём для примера файл mp (польский формат).
>Он может быть не юникодный, но в заголовке указана кодировка.
Основной вопрос станет ли он работать хуже чем работает сейчас сейчас там используется TStringList.LoadFromStream(VDataStream) вот и нужно смотреть что оно там в новой делфи загрузит.

> Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?
Для kml/kmz есть определения кодировки, так что тут проблем нет.

> Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.
У нас вообще нет сохранения векторных тайлов кроме конвертации kml<->kmz, но там проблема не возникает, как и для сохранения растров.

> У HashFunction есть расчёт хэша по WideString?
Там есть расчет хэша по текущему типу строк, его более чем достаточно.

> Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
Что тебя тут не устраивает?

> мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая
Увы, но я это переделывать буду, только если сам столкнусь с такой проблемой или за отдельные деньги, а до тех пор юникод наше все.

>Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.
Ну, не считая импорта mp (тупого и такого наколенно-ущербного что дальше некуда) это первая реальная проблема о которой ты напомнил, но о ней напоминает и компилятор.

> Это только то что я помню сходу. Но даже этого достаточно.
Итого - ничего серьезного. Можно пробовать делать ночные сборки. Спасибо что успокоил.

vasketsov

20-04-2015 15:27

manager   ~0015623

Last edited: 20-04-2015 15:28

 >TStringList.LoadFromStream ... нужно смотреть что оно там в новой делфи загрузит
А посмореть никак что ли? )))
Хотя куда более интересно, что оно сохранит, и как потом быть, если надо запустить старую версию саса.

>У нас вообще нет сохранения векторных тайлов
Уважаемый, Вы невнимательны. Речь была не о векторных тайлах, а о файлах вообще. Пример - настройки. В нужной пользователю кодировке.

>Что тебя тут не устраивает?
В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))

>но я это переделывать буду, только если сам столкнусь с такой проблемой
Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе? В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.

vdemidov

20-04-2015 17:48

manager   ~0015625

> А посмореть никак что ли? )))
Увы, на работе делфи нету, так что никак.

> Речь была не о векторных тайлах, а о файлах вообще.
Файлы вообще нас не интересуют. Нас интересуют текстовые файлы. Причем каждый конкретный тип сохраняемых данных требует своего подхода: некоторые форматы подразумевают юникод и уже сейчас сохраняются в UTF8, некоторые допускают только Ansi и соответственно уже сейчас там прописано использование AnsiString и следовательно будет работать как и сейчас. А некоторые типа ини-файлов разницы никакой лишь бы работало. Поэтому нужно говорить о конкретных файлах, а не в общем.

> В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))
Хуже чем сейчас не будет, это факт.

>Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе?
И чем это их спасет? Но в общем и целом никто пока не призывает совсем отказываться от сборки в 2007 делфе. Речь о начале сборки в новой.

> В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.
Странно. Почему не удивлен. Я ведь эту позицию, что я никому ничем не обязан и это опенсорс, озвучивал всего пару десятков раз.

vasketsov

20-04-2015 18:56

manager   ~0015626

> чем это их спасет?
файлы будут неюникодные.

>некоторые типа ини-файлов разницы никакой
Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?

>Речь о начале сборки в новой
Разве?
Читаю в заголовке: "Переход на версию Delphi с полной поддержкой юникода".
Мы о разному понимаем слово "Переход"?
Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.

>Речь о начале сборки в новой
Не вижу связи между словои "Переход" и словосочетанием "начале сборки в новой".
Ты именно предлагаешь ночнушки начать собирать в XE2 и только в этой версии?
Так это вообще не переход. Это даже не запах его на горизонте. Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется.

vdemidov

20-04-2015 19:30

manager   ~0015627

> файлы будут неюникодные.
Какие конкретно и что это им даст?

> Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?
Нужно проверять конкретные места и если не работает заводить отдельные инциденты. Но ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси, а писать в своем родном формате.
 
>Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.
Ну, это часть перехода. И ИМХО таки уже пора.

>Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется.
Когда кажется - креститься нужно.

vasketsov

20-04-2015 21:31

manager   ~0015628

>ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси
Это минимум, без которого говорить о переходе более чем наивно.
Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате?

vdemidov

21-04-2015 06:57

manager   ~0015630

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

Zed, можешь сбилдить XE2 версию? А еще лучше было бы сделать хотя бы еженедельную сборку дебажной XE2 версии.

vasketsov

21-04-2015 08:25

manager   ~0015631

>Вот, наконец, хоть какая-то польза
Ты издеваешься?
Ещё вчера в первом же сообщении я написал про "читалки" файлов. Потом конкретно уточнил "например, настроек" - ты это прочитал вообще, или просто по диагонали?
Если тебе кажется, что я излишне прямолинеен - это не повод не читать, что тебе пишут. Особенно когда в написанном содержится ответ на вопрос. Тогда бы и "переливания" удалось избежать.

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

>еженедельную
Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.

А каких именно "новых плюшек делфи" не хватает, кроме юникода?

vdemidov

21-04-2015 09:13

manager   ~0015632

>Ещё вчера в первом же сообщении я написал про "читалки" файлов.
Это общий свист ни о чем. Конкретное предложение это добавить чтение юникодных конфигов в текущую версию. Сейчас создам отдельный инцидент.

>А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты.
Только ini-шки. Скрипты пока будут жить в виде Ansi - для генерации урлов этого более чем достаточно.

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

> Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.
Ну, это если есть возможность. А на первое время хотя бы раз в неделю.

> А каких именно "новых плюшек делфи" не хватает, кроме юникода?
Ну лично мне, не хватает дженериков. Плюс некоторые плюшки самой среды разработки.

zed

21-04-2015 16:15

manager   ~0015633

Периодически собираю для себя юникодную версию и запускаю прямо из рабочего каталога неюникодной версии, а потом наоборот, запускаю неюникодную. Соответственно, ни в той, ни в другой версии проблем с ini, zmp, метками и кэшем Беркли не наблюдаю. Настройки как хранились в win1251, так и хранятся.

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

Ну и наконец, по поводу "плюшек" новых делфи. Лично я за то, чтобы в коде сохранялась совместимость с D2007.

vasketsov

21-04-2015 17:35

manager   ~0015634

Last edited: 21-04-2015 17:36

 >не хватает дженериков
А мне Exit() не хватает.

>сохранялась совместимость
Очень тяжело себя сдерживать. Вчера только перед коммитом опомнился и вычищал такие вот Exit('') и т.п.

Вот пример:
TIeEmbeddedProtocol.LoadDataToStream

var
VContentType: string;

получается:
VDomain.LoadBinaryByFilePath(VFilePath, VContentType)

юзается:
PWideChar(WideString(VContentType))

С таким приведением типов компилятор просто затыкается и молчит.
Между тем совершенно непонятно, что делает здесь тип String, если ContentType определён как AnsiString:
  IInternalDomainInfoProvider = interface
    ['{CD84B08E-E84B-4688-9D9A-A9A34F29139D}']
    function LoadBinaryByFilePath(
      const AFilePath: string;
      out AContentType: string
    ): IBinaryData;
  end;

vdemidov

21-04-2015 18:01

manager   ~0015636

> Очень тяжело себя сдерживать.
Именно

> Настройки как хранились в win1251, так и хранятся.
C одной стороны хорошо тем, что две версии работают без усилий.
Но тогда получается будут потери данных в юникоднрой версии. Так что хотелку 0002690 стоит реализовать.

zed

21-04-2015 19:05

manager   ~0015638

>Очень тяжело себя сдерживать
Сдерживались же до этого, и вроде все живы.

В новых компиляторах много сюрпризов может быть: http://alexander-bagel.blogspot.com/2015/04/8.html В идеале, если и менять компилятор, то на самый стабильный. Кто готов назвать такой в ветке XE? Сама по себе XE2 уже устарела (выпощена в 2011 году). А с более новыми версиями (к примеру, если замахнуться на XE8), боюсь у нас с Toolbar2000 и EmbeddedWB будут проблемы.

vasketsov

21-04-2015 19:44

manager   ~0015639

>Кто готов назвать такой в ветке XE?
По отзывам - как раз XE8 )))

>XE2 уже устарела
Переход на XEn, где n>2, вызывает сомнения.
В частности, на XE4 проект не собирается из-за префиксов, см. выше в теме.
Имхуется, что XE2 - необходимое зло, то самое, которое надо минимизировать, и без которого (перехода на которое) никак не двинуться дальше.

>EmbeddedWB
В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много.

vasketsov

21-04-2015 22:52

manager   ~0015641

Сохранил GetUrlScript.txt в юникоде и открыл в супер-zed-отладчике - вот так он выглядит:

яюv

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

Собственно, поведение вполне ожидаемое, что и было написано выше.

Конкретно за паскальскрипты - это будете фиксить, или просто надо будет анонсировать, что скрипты не юникодные?

vasketsov

21-04-2015 22:55

manager   ~0015642

Там же вдогонку: если скрипт был в UTF8, то читается он как Ansi:

п»їvar res:string;
    i:byte;
    osX,osY,prX,prY:integer;
begin
   res:=''; // проверка

vasketsov

22-04-2015 01:03

manager   ~0015644

Хинты в главном меню отображаются знаками вопроса

zed

22-04-2015 06:04

manager   ~0015646

>В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много.
А Toolbar2000 тоже предлагаешь выпилить?

vasketsov

22-04-2015 10:44

manager   ~0015659

>Toolbar2000
Успеют, с нашей-то скоростью )))

zed

22-04-2015 10:47

manager   ~0015662

Куда там. Судя по всему, мёртв он давно.

vasketsov

22-04-2015 10:58

manager   ~0015666

Упс. Ну тогда будем решать по факту. Допиливать по месту или искать аналоги/замену.

vdemidov

22-04-2015 11:00

manager   ~0015667

Ну нам нужно искать замену не Toolbar2000, а TBX, а для него есть аналог SpTBX

vasketsov

25-04-2015 10:04

manager   ~0015739

На 2010-й дельфе пробовали пускать проект?
Я пожалуй откажусь от сборки под 2007, а то что-то какие-то косяки при установке 2007 на новую ось на ноуте. Версии 2010 и XE2 оставлю. Не ради новых фич, а просто жаль время разбираться, фичи пока подождут.

zed

25-04-2015 10:19

manager   ~0015740

А смысл? Там же тот же юникод. Тогда уж переходи на XE2 сразу.

vasketsov

25-04-2015 10:44

manager   ~0015741

Так XE2 и так на соседнем разделе есть. 2010 для других проектов надо поставить.

GunSmoker

21-07-2015 06:16

developer   ~0016195

> "Под XE4 проект не собирается капитально, юниты надо именовать с префиксами."

Достаточно в опции проекта вписать нужные namespace.

vdemidov

26-10-2015 10:51

manager   ~0016627

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

zed

26-10-2015 12:15

manager   ~0016628

В дополнение к D2007 или вместо?

vdemidov

26-10-2015 12:22

manager   ~0016629

Ну, на первое время, конечно, в дополнение. А там посмотрим по количеству багов и отзывов. Если будет слишком мало, то и вместо. Но вообще смотри по возможностям твоего билд сервера :) Как решишь так и будет.

zed

26-10-2015 17:33

manager   ~0016632

Ок, в ночнушке теперь будет ещё один exe: SASPlanet.Unicode.exe - дебажная версия, собранная в XE2. Так же, пришлось добавить midas.dll из поставки XE2, чтобы там работали sml метки (см. http://www.sasgis.org/forum/viewtopic.php?f=47&t=2348).

vdemidov

26-10-2015 18:28

manager   ~0016633

Спасибо большое. Пока пусть втихую появляется. А потом сделаем объявление с просьбой активнее тестировать.

vdemidov

28-10-2015 19:48

manager   ~0016644

В общем, после того как соберется сегодняшняя ночная версия, я не вижу никаких препятствий для объявления о тестировании юникодной версии.

zed

28-10-2015 20:00

manager   ~0016645

Да, можешь анонсировать. Хотя, сомневаюсь, что народ сильно заинтересуется.

vdemidov

30-10-2015 10:00

manager   ~0016652

Заглянул в модуль libdb51 и теперь не понимаю как оно вообще работает в юникодной версии (по всем законом не должно).

Функция загрузки процедур из dll выглядит вот так:

  procedure LoadProc(var proc; const procName: string);
  begin
    pointer(proc) := GetProcAddress(DllHandle, pchar(procName));
    if pointer(proc) = nil then begin
      raise EBerkeleyDBExeption.Create(
        'Function ''' + procName + ''' not found in ' + DllName
      );
    end;
  end;
Но функция GetProcAddress определена только для PAnsiChar. Как она хавает юникодные строки я не понимаю.

zed

30-10-2015 10:14

manager   ~0016653

А WinApi.Windows.pas из XE2 говорит нам что:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;
begin
  if ULONG_PTR(lpProcName) shr 16 = 0 then // IS_INTRESOURCE
    Result := GetProcAddress(hModule, LPCSTR(lpProcName))
  else
    Result := GetProcAddress(hModule, LPCSTR(AnsiString(lpProcName)));
end;

zed

30-10-2015 10:15

manager   ~0016654

Но можно и пофиксить, для надёжности.

vdemidov

30-10-2015 10:25

manager   ~0016655

Понятно. Это была настолько популярная бага, что для нее сделали костыль. Думаю лучше пофиксить для беркли и пнг

zed

01-11-2015 10:53

manager   ~0016677

Using UTF-8 as the internal representation for strings in C and C++ with Visual Studio - та же идея работы со строками, что и в mORMot фреймворке, о котором я писал выше.

По-моему, крутейшее решение.

vdemidov

02-11-2015 07:51

manager   ~0016680

Решение крутейшее, но не для делфи, где почти все компоненты и инструменты заточены на работу с юникодом. Например, как работать с ini файлом в utf-8 без полной перекодировки его в utf-16, если стандартный компонент для работы с ini-файлами в юникодной делфи работает только в utf-16. Но можешь попробовать в отдельной ветке.

zed

02-11-2015 11:14

manager   ~0016683

>Например, как работать с ini файлом в utf-8
В SynCommons есть соответствующие функции. Там вообще много чего есть.

>Но можешь попробовать в отдельной ветке.
Спасибо за разрешение, но нет.

vdemidov

02-11-2015 11:21

manager   ~0016684

>>Но можешь попробовать в отдельной ветке.
>Спасибо за разрешение, но нет.
Жаль. Было бы интересно посмотреть что из этого выйдет.

vdemidov

10-06-2016 07:40

manager   ~0017325

Учитывая последние изменения в билд системе, похоже, что эту хотелку можно закрывать как выполненную?

zed

10-06-2016 17:31

manager   ~0017333

Да.

Issue History

Date Modified Username Field Change
16-09-2013 06:56 vdemidov New Issue
16-09-2013 06:56 vdemidov Tag Attached: юникод
16-09-2013 06:56 vdemidov Status new => confirmed
16-09-2013 06:57 vdemidov Relationship added child of 0000626
16-09-2013 06:57 vdemidov Relationship added child of 0000181
16-09-2013 16:34 vasketsov Note Added: 0012805
16-09-2013 17:05 vdemidov Note Added: 0012806
16-09-2013 17:12 vasketsov Note Added: 0012808
16-09-2013 17:16 vdemidov Note Added: 0012809
16-09-2013 17:27 vasketsov Note Added: 0012812
17-09-2013 17:00 vdemidov Relationship added parent of 0002169
30-11-2013 17:45 zed Relationship added child of 0002278
04-09-2014 06:00 zed Note Added: 0014605
04-09-2014 18:24 vdemidov Note Added: 0014608
04-09-2014 19:13 zed Note Added: 0014609
04-09-2014 20:37 vdemidov Note Added: 0014610
06-09-2014 17:32 vdemidov Issue cloned: 0002493
06-09-2014 17:32 vdemidov Relationship added parent of 0002493
20-11-2014 07:16 vdemidov Relationship added has duplicate 0002553
19-02-2015 11:38 vdemidov Relationship added related to 0002107
20-04-2015 07:21 vdemidov Note Added: 0015615
20-04-2015 07:54 zed Note Added: 0015616
20-04-2015 12:59 vasketsov Note Added: 0015617
20-04-2015 13:54 vdemidov Note Added: 0015619
20-04-2015 14:33 vasketsov Note Added: 0015620
20-04-2015 14:54 vdemidov Note Added: 0015622
20-04-2015 15:27 vasketsov Note Added: 0015623
20-04-2015 15:28 vasketsov Note Edited: 0015623
20-04-2015 17:48 vdemidov Note Added: 0015625
20-04-2015 18:56 vasketsov Note Added: 0015626
20-04-2015 19:30 vdemidov Note Added: 0015627
20-04-2015 21:31 vasketsov Note Added: 0015628
21-04-2015 06:57 vdemidov Note Added: 0015630
21-04-2015 08:25 vasketsov Note Added: 0015631
21-04-2015 09:13 vdemidov Note Added: 0015632
21-04-2015 09:29 vdemidov Relationship added parent of 0002690
21-04-2015 16:15 zed Note Added: 0015633
21-04-2015 17:35 vasketsov Note Added: 0015634
21-04-2015 17:36 vasketsov Note Edited: 0015634
21-04-2015 17:38 vdemidov Relationship added parent of 0002691
21-04-2015 18:01 vdemidov Note Added: 0015636
21-04-2015 19:05 zed Note Added: 0015638
21-04-2015 19:44 vasketsov Note Added: 0015639
21-04-2015 22:52 vasketsov Note Added: 0015641
21-04-2015 22:55 vasketsov Note Added: 0015642
22-04-2015 01:03 vasketsov Note Added: 0015644
22-04-2015 06:04 zed Note Added: 0015646
22-04-2015 10:44 vasketsov Note Added: 0015659
22-04-2015 10:47 zed Note Added: 0015662
22-04-2015 10:58 vasketsov Note Added: 0015666
22-04-2015 11:00 vdemidov Note Added: 0015667
25-04-2015 10:04 vasketsov Note Added: 0015739
25-04-2015 10:19 zed Note Added: 0015740
25-04-2015 10:44 vasketsov Note Added: 0015741
26-04-2015 11:28 vdemidov Relationship added child of 0002703
26-04-2015 13:41 vdemidov Relationship added parent of 0002705
26-04-2015 13:49 vdemidov Relationship deleted child of 0002703
21-07-2015 06:16 GunSmoker Note Added: 0016195
03-08-2015 20:04 GunSmoker Relationship added related to 0002781
03-08-2015 20:06 vdemidov Relationship replaced parent of 0002781
09-10-2015 09:06 vdemidov Relationship replaced child of 0002690
26-10-2015 10:51 vdemidov Note Added: 0016627
26-10-2015 12:15 zed Note Added: 0016628
26-10-2015 12:22 vdemidov Note Added: 0016629
26-10-2015 17:33 zed Note Added: 0016632
26-10-2015 18:28 vdemidov Note Added: 0016633
27-10-2015 07:51 vdemidov Relationship added parent of 0002868
27-10-2015 21:00 vdemidov Relationship added parent of 0002869
28-10-2015 19:48 vdemidov Note Added: 0016644
28-10-2015 20:00 zed Note Added: 0016645
29-10-2015 11:05 vdemidov Relationship added parent of 0002877
30-10-2015 10:00 vdemidov Note Added: 0016652
30-10-2015 10:14 zed Note Added: 0016653
30-10-2015 10:15 zed Note Added: 0016654
30-10-2015 10:25 vdemidov Note Added: 0016655
30-10-2015 14:17 vdemidov Relationship added parent of 0002880
30-10-2015 14:17 vdemidov Relationship added parent of 0002881
30-10-2015 14:17 vdemidov Relationship added parent of 0002882
30-10-2015 14:18 vdemidov Relationship added parent of 0002883
01-11-2015 10:53 zed Note Added: 0016677
02-11-2015 07:51 vdemidov Note Added: 0016680
02-11-2015 11:14 zed Note Added: 0016683
02-11-2015 11:21 vdemidov Note Added: 0016684
03-11-2015 09:13 vdemidov Relationship added parent of 0002047
05-11-2015 08:08 vdemidov Relationship replaced parent of 0002690
05-11-2015 09:15 vdemidov Relationship added parent of 0002891
05-11-2015 09:31 vdemidov Relationship added parent of 0002892
11-11-2015 15:30 vdemidov Relationship added parent of 0002900
11-11-2015 15:31 vdemidov Relationship added parent of 0002901
03-03-2016 11:55 vdemidov Relationship added parent of 0002975
10-06-2016 07:39 vdemidov Target Version 42xxxx => 191221
10-06-2016 07:40 vdemidov Note Added: 0017325
10-06-2016 08:37 vdemidov Target Version 191221 => 160707
10-06-2016 17:31 zed Note Added: 0017333
11-06-2016 17:45 vdemidov Status confirmed => resolved
11-06-2016 17:45 vdemidov Fixed in Version => 160707
11-06-2016 17:45 vdemidov Resolution open => fixed
11-06-2016 17:45 vdemidov Assigned To => zed
12-06-2016 09:09 vdemidov Relationship replaced related to 0002900
26-11-2016 09:41 zed Relationship added related to 0003155
08-08-2025 13:24 zed Category Хотелка => Хотелка / Feature request