Anonymous | Login | Signup for a new account | 21-11-24 12:30 UTC |
All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0002166 | SAS.Планета | [All Projects] Хотелка | public | 16-09-2013 06:56 | 26-11-2016 09:41 | ||||
Reporter | vdemidov | ||||||||
Assigned To | zed | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 121010 | ||||||||
Target Version | 160707 | Fixed in Version | 160707 | ||||||
Summary | 0002166: Переход на версию Delphi с полной поддержкой юникода | ||||||||
Description | Сейчас для сборки как основная используется Delphi 2007. Но только начиная с Delphi 2009 был полный переход на юникод. Для полной поддержки юникода в программе нужно перейти на что-то более свежее. | ||||||||
Tags | юникод | ||||||||
Attached Files | |||||||||
Relationships | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Notes | |
(0012805) vasketsov (manager) 16-09-2013 16:34 |
XE2 или XE4? |
(0012806) vdemidov (manager) 16-09-2013 17:05 |
Да хоть XE5. У меня XE2 установлена. А какую Zed на сервер для сборки поставит та и будет, я не думаю, что там принципиальная разница будет. |
(0012808) vasketsov (manager) 16-09-2013 17:12 |
Под XE4 проект не собирается капитально, юниты надо именовать с префиксами. Если нет желания перелопачивать всё и вся - значит XE2. |
(0012809) vdemidov (manager) 16-09-2013 17:16 |
Ну тебе виднее. Я не пробовал. Но переход на юникод нужен однозначно. |
(0012812) vasketsov (manager) 16-09-2013 17:27 |
Я ставил XE4 чтобы оттуда свистнуть файлы для Sensor API (и ещё несколько зависимых, которых в XE2 нет). Но даже после правки имён юнитов просто так их заюзать в XE2 не вышло из-за delayed. Сделал вывод, что переход 2007 -> XEn для n>2 слишком сложен для одновременной поддержки обоих компиляторов. Возможно где-то конечно и недодумал. Также для GR32 (или чего-то такого столь же важного) нет поддержки XE4. |
(0014605) zed (manager) 04-09-2014 06:00 |
Открыл для себя фреймворк 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. |
(0014608) vdemidov (manager) 04-09-2014 18:24 |
Ну так давай, хотя, это несколько расходится с моими мыслями о переходе везде на 2-х байтный юникод, что бы потом в интерфейсах использовать WideString с меньшими расходами, но это такое отдаленное будущее, что бог с ним... Мне честно говоря очень не хватает новых плюшек делфи. |
(0014609) zed (manager) 04-09-2014 19:13 |
>использовать WideString Это тип строк работает убийственно медленно. Их вообще не стоит использовать без острой необходимости. Лучше старый добрый PAnsiChar, через который и utf-8 прекрасно передаётся. |
(0014610) vdemidov (manager) 04-09-2014 20:37 |
> Это тип строк работает убийственно медленно. За все нужно платить. Зато эти строки можно передавать в dll на любом языке скомпилированную в любом компиляторе и обратно без малейших проблем. А это для интерфейсов достаточно важно. Но я же говорю, что это не существенно и не предлагаю так делать. И вообще я за скорейший переход на более свежую версию делфи. |
(0015615) vdemidov (manager) 20-04-2015 07:21 |
Какие у нас остались проблемы с переходом на юникодную версию делфи кроме регекспов? |
(0015616) zed (manager) 20-04-2015 07:54 |
А что с регэкспами? Там же widestrig под юникодом. Медленно, но надежно. Думаю, можно выпускать юникодную сборку для тестов и звать китайцев, чтобы они нас багрепортами забросали. Тогда будет более-менее понятно. |
(0015617) vasketsov (manager) 20-04-2015 12:59 |
А парсеры и читалки уже умеют отличать буфер и файл с диска соответственно, юникодный он или нет? А сохранять файлы всегда в юникоде будете? |
(0015619) vdemidov (manager) 20-04-2015 13:54 |
Об этом и вопрос. В большинстве мест там уже есть определение типа текстовых файлов. Но везде ли оно правильно сделано? |
(0015620) vasketsov (manager) 20-04-2015 14:33 |
>В большинстве мест там уже есть определение типа текстовых файлов Хм. Видимо мы друг друга не очень понимаем. Но мне кажется, что про большинство мест ты несколько погорячился. Возьмём для примера файл mp (польский формат). Он может быть не юникодный, но в заголовке указана кодировка. Я не помню такого куска кода, который бы это нюхал и конвертировал в юникод или текущую кодировку, а без этого что-то искать в общем случае бессмысленно. И в принципе я поднимал вопрос с определением того, вот конкретно взятый буфер с текстом юникодный или нет, интереса оно у вас не вызвало. А между тем это первое, что надо делать после чтения любого файла, если мы хотим с ним работать как с текстом. У меня есть такой пример в коде внутреннего httpd. Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется? Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет. У HashFunction есть расчёт хэша по WideString? Нет. А между тем, где оно будет форсироваться после проверки, оно должно быть. Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП. В принципе по каждому сохраняемому типу файлов надо понимать, в каком виде надо уметь их сохранять. Потому что если потом встать в позу, что мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая. Это касается привязок, экспортов и т.п. Даже там, где нет юникода, может прокатить AnsiString и прямое указние кодировки, но перекодировка обязана возникнуть, а сейчас её нет. Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь. Это только то что я помню сходу. Но даже этого достаточно. |
(0015622) vdemidov (manager) 20-04-2015 14:54 |
>Возьмём для примера файл mp (польский формат). >Он может быть не юникодный, но в заголовке указана кодировка. Основной вопрос станет ли он работать хуже чем работает сейчас сейчас там используется TStringList.LoadFromStream(VDataStream) вот и нужно смотреть что оно там в новой делфи загрузит. > Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется? Для kml/kmz есть определения кодировки, так что тут проблем нет. > Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет. У нас вообще нет сохранения векторных тайлов кроме конвертации kml<->kmz, но там проблема не возникает, как и для сохранения растров. > У HashFunction есть расчёт хэша по WideString? Там есть расчет хэша по текущему типу строк, его более чем достаточно. > Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП. Что тебя тут не устраивает? > мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая Увы, но я это переделывать буду, только если сам столкнусь с такой проблемой или за отдельные деньги, а до тех пор юникод наше все. >Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь. Ну, не считая импорта mp (тупого и такого наколенно-ущербного что дальше некуда) это первая реальная проблема о которой ты напомнил, но о ней напоминает и компилятор. > Это только то что я помню сходу. Но даже этого достаточно. Итого - ничего серьезного. Можно пробовать делать ночные сборки. Спасибо что успокоил. |
(0015623) vasketsov (manager) 20-04-2015 15:27 edited on: 20-04-2015 15:28 |
>TStringList.LoadFromStream ... нужно смотреть что оно там в новой делфи загрузит А посмореть никак что ли? ))) Хотя куда более интересно, что оно сохранит, и как потом быть, если надо запустить старую версию саса. >У нас вообще нет сохранения векторных тайлов Уважаемый, Вы невнимательны. Речь была не о векторных тайлах, а о файлах вообще. Пример - настройки. В нужной пользователю кодировке. >Что тебя тут не устраивает? В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть )) >но я это переделывать буду, только если сам столкнусь с такой проблемой Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе? В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание. |
(0015625) vdemidov (manager) 20-04-2015 17:48 |
> А посмореть никак что ли? ))) Увы, на работе делфи нету, так что никак. > Речь была не о векторных тайлах, а о файлах вообще. Файлы вообще нас не интересуют. Нас интересуют текстовые файлы. Причем каждый конкретный тип сохраняемых данных требует своего подхода: некоторые форматы подразумевают юникод и уже сейчас сохраняются в UTF8, некоторые допускают только Ansi и соответственно уже сейчас там прописано использование AnsiString и следовательно будет работать как и сейчас. А некоторые типа ини-файлов разницы никакой лишь бы работало. Поэтому нужно говорить о конкретных файлах, а не в общем. > В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть )) Хуже чем сейчас не будет, это факт. >Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе? И чем это их спасет? Но в общем и целом никто пока не призывает совсем отказываться от сборки в 2007 делфе. Речь о начале сборки в новой. > В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание. Странно. Почему не удивлен. Я ведь эту позицию, что я никому ничем не обязан и это опенсорс, озвучивал всего пару десятков раз. |
(0015626) vasketsov (manager) 20-04-2015 18:56 |
> чем это их спасет? файлы будут неюникодные. >некоторые типа ини-файлов разницы никакой Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется? >Речь о начале сборки в новой Разве? Читаю в заголовке: "Переход на версию Delphi с полной поддержкой юникода". Мы о разному понимаем слово "Переход"? Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница. >Речь о начале сборки в новой Не вижу связи между словои "Переход" и словосочетанием "начале сборки в новой". Ты именно предлагаешь ночнушки начать собирать в XE2 и только в этой версии? Так это вообще не переход. Это даже не запах его на горизонте. Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется. |
(0015627) vdemidov (manager) 20-04-2015 19:30 |
> файлы будут неюникодные. Какие конкретно и что это им даст? > Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется? Нужно проверять конкретные места и если не работает заводить отдельные инциденты. Но ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси, а писать в своем родном формате. >Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница. Ну, это часть перехода. И ИМХО таки уже пора. >Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется. Когда кажется - креститься нужно. |
(0015628) vasketsov (manager) 20-04-2015 21:31 |
>ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси Это минимум, без которого говорить о переходе более чем наивно. Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате? |
(0015630) vdemidov (manager) 21-04-2015 06:57 |
> Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате? Вот, наконец, хоть какая-то польза из этого переливания из пустого в порожнее. Нужно проверить как юникодная версия сохраняет конфиги и читает их. Zed, можешь сбилдить XE2 версию? А еще лучше было бы сделать хотя бы еженедельную сборку дебажной XE2 версии. |
(0015631) vasketsov (manager) 21-04-2015 08:25 |
>Вот, наконец, хоть какая-то польза Ты издеваешься? Ещё вчера в первом же сообщении я написал про "читалки" файлов. Потом конкретно уточнил "например, настроек" - ты это прочитал вообще, или просто по диагонали? Если тебе кажется, что я излишне прямолинеен - это не повод не читать, что тебе пишут. Особенно когда в написанном содержится ответ на вопрос. Тогда бы и "переливания" удалось избежать. >проверить как юникодная версия сохраняет конфиги и читает их А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты. А поскольку ini-шки у нас правятся в том числе руками, для проверки этого не обязательно собирать U-версию и забирать из-под неё ini-шки, достаточно обычного блокнота. И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный. >еженедельную Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную. А каких именно "новых плюшек делфи" не хватает, кроме юникода? |
(0015632) vdemidov (manager) 21-04-2015 09:13 |
>Ещё вчера в первом же сообщении я написал про "читалки" файлов. Это общий свист ни о чем. Конкретное предложение это добавить чтение юникодных конфигов в текущую версию. Сейчас создам отдельный инцидент. >А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты. Только ini-шки. Скрипты пока будут жить в виде Ansi - для генерации урлов этого более чем достаточно. > И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный. Вот и нужно было об этом написать. > Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную. Ну, это если есть возможность. А на первое время хотя бы раз в неделю. > А каких именно "новых плюшек делфи" не хватает, кроме юникода? Ну лично мне, не хватает дженериков. Плюс некоторые плюшки самой среды разработки. |
(0015633) zed (manager) 21-04-2015 16:15 |
Периодически собираю для себя юникодную версию и запускаю прямо из рабочего каталога неюникодной версии, а потом наоборот, запускаю неюникодную. Соответственно, ни в той, ни в другой версии проблем с ini, zmp, метками и кэшем Беркли не наблюдаю. Настройки как хранились в win1251, так и хранятся. По поводу билдов XE2, у меня есть задумка доделать автоматическое обновление SAS и добавить канал обновлений Nightly Unicode, чтобы все желающие могли тестировать. Соответственно, и билды в тот канал будут заливаться одновременно с билдами обычной ночнушки. Ну и наконец, по поводу "плюшек" новых делфи. Лично я за то, чтобы в коде сохранялась совместимость с D2007. |
(0015634) vasketsov (manager) 21-04-2015 17:35 edited on: 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; |
(0015636) vdemidov (manager) 21-04-2015 18:01 |
> Очень тяжело себя сдерживать. Именно > Настройки как хранились в win1251, так и хранятся. C одной стороны хорошо тем, что две версии работают без усилий. Но тогда получается будут потери данных в юникоднрой версии. Так что хотелку 0002690 стоит реализовать. |
(0015638) zed (manager) 21-04-2015 19:05 |
>Очень тяжело себя сдерживать Сдерживались же до этого, и вроде все живы. В новых компиляторах много сюрпризов может быть: http://alexander-bagel.blogspot.com/2015/04/8.html В идеале, если и менять компилятор, то на самый стабильный. Кто готов назвать такой в ветке XE? Сама по себе XE2 уже устарела (выпощена в 2011 году). А с более новыми версиями (к примеру, если замахнуться на XE8), боюсь у нас с Toolbar2000 и EmbeddedWB будут проблемы. |
(0015639) vasketsov (manager) 21-04-2015 19:44 |
>Кто готов назвать такой в ветке XE? По отзывам - как раз XE8 ))) >XE2 уже устарела Переход на XEn, где n>2, вызывает сомнения. В частности, на XE4 проект не собирается из-за префиксов, см. выше в теме. Имхуется, что XE2 - необходимое зло, то самое, которое надо минимизировать, и без которого (перехода на которое) никак не двинуться дальше. >EmbeddedWB В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много. |
(0015641) vasketsov (manager) 21-04-2015 22:52 |
Сохранил GetUrlScript.txt в юникоде и открыл в супер-zed-отладчике - вот так он выглядит: яюv дальше визуально читаемый текст через пробелы, в реальности нулевые символы, поэтому даже не копируется. Собственно, поведение вполне ожидаемое, что и было написано выше. Конкретно за паскальскрипты - это будете фиксить, или просто надо будет анонсировать, что скрипты не юникодные? |
(0015642) vasketsov (manager) 21-04-2015 22:55 |
Там же вдогонку: если скрипт был в UTF8, то читается он как Ansi: п»їvar res:string; i:byte; osX,osY,prX,prY:integer; begin res:=''; // проверка |
(0015644) vasketsov (manager) 22-04-2015 01:03 |
Хинты в главном меню отображаются знаками вопроса |
(0015646) zed (manager) 22-04-2015 06:04 |
>В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много. А Toolbar2000 тоже предлагаешь выпилить? |
(0015659) vasketsov (manager) 22-04-2015 10:44 |
>Toolbar2000 Успеют, с нашей-то скоростью ))) |
(0015662) zed (manager) 22-04-2015 10:47 |
Куда там. Судя по всему, мёртв он давно. |
(0015666) vasketsov (manager) 22-04-2015 10:58 |
Упс. Ну тогда будем решать по факту. Допиливать по месту или искать аналоги/замену. |
(0015667) vdemidov (manager) 22-04-2015 11:00 |
Ну нам нужно искать замену не Toolbar2000, а TBX, а для него есть аналог SpTBX |
(0015739) vasketsov (manager) 25-04-2015 10:04 |
На 2010-й дельфе пробовали пускать проект? Я пожалуй откажусь от сборки под 2007, а то что-то какие-то косяки при установке 2007 на новую ось на ноуте. Версии 2010 и XE2 оставлю. Не ради новых фич, а просто жаль время разбираться, фичи пока подождут. |
(0015740) zed (manager) 25-04-2015 10:19 |
А смысл? Там же тот же юникод. Тогда уж переходи на XE2 сразу. |
(0015741) vasketsov (manager) 25-04-2015 10:44 |
Так XE2 и так на соседнем разделе есть. 2010 для других проектов надо поставить. |
(0016195) GunSmoker (developer) 21-07-2015 06:16 |
> "Под XE4 проект не собирается капитально, юниты надо именовать с префиксами." Достаточно в опции проекта вписать нужные namespace. |
(0016627) vdemidov (manager) 26-10-2015 10:51 |
Предлагаю начинать выпускать ночные версии собранные в XE2. Это пока еще не даст нам полную поддержку юникода, но хотя бы позволит убедится, что юникодная версия работает не хуже собранной в D2007. |
(0016628) zed (manager) 26-10-2015 12:15 |
В дополнение к D2007 или вместо? |
(0016629) vdemidov (manager) 26-10-2015 12:22 |
Ну, на первое время, конечно, в дополнение. А там посмотрим по количеству багов и отзывов. Если будет слишком мало, то и вместо. Но вообще смотри по возможностям твоего билд сервера :) Как решишь так и будет. |
(0016632) zed (manager) 26-10-2015 17:33 |
Ок, в ночнушке теперь будет ещё один exe: SASPlanet.Unicode.exe - дебажная версия, собранная в XE2. Так же, пришлось добавить midas.dll из поставки XE2, чтобы там работали sml метки (см. http://www.sasgis.org/forum/viewtopic.php?f=47&t=2348). |
(0016633) vdemidov (manager) 26-10-2015 18:28 |
Спасибо большое. Пока пусть втихую появляется. А потом сделаем объявление с просьбой активнее тестировать. |
(0016644) vdemidov (manager) 28-10-2015 19:48 |
В общем, после того как соберется сегодняшняя ночная версия, я не вижу никаких препятствий для объявления о тестировании юникодной версии. |
(0016645) zed (manager) 28-10-2015 20:00 |
Да, можешь анонсировать. Хотя, сомневаюсь, что народ сильно заинтересуется. |
(0016652) vdemidov (manager) 30-10-2015 10:00 |
Заглянул в модуль libdb51 и теперь не понимаю как оно вообще работает в юникодной версии (по всем законом не должно). Функция загрузки процедур из dll выглядит вот так:
Но функция GetProcAddress определена только для PAnsiChar. Как она хавает юникодные строки я не понимаю. |
(0016653) zed (manager) 30-10-2015 10:14 |
А WinApi.Windows.pas из XE2 говорит нам что: |
(0016654) zed (manager) 30-10-2015 10:15 |
Но можно и пофиксить, для надёжности. |
(0016655) vdemidov (manager) 30-10-2015 10:25 |
Понятно. Это была настолько популярная бага, что для нее сделали костыль. Думаю лучше пофиксить для беркли и пнг |
(0016677) zed (manager) 01-11-2015 10:53 |
Using UTF-8 as the internal representation for strings in C and C++ with Visual Studio - та же идея работы со строками, что и в mORMot фреймворке, о котором я писал выше. По-моему, крутейшее решение. |
(0016680) vdemidov (manager) 02-11-2015 07:51 |
Решение крутейшее, но не для делфи, где почти все компоненты и инструменты заточены на работу с юникодом. Например, как работать с ini файлом в utf-8 без полной перекодировки его в utf-16, если стандартный компонент для работы с ini-файлами в юникодной делфи работает только в utf-16. Но можешь попробовать в отдельной ветке. |
(0016683) zed (manager) 02-11-2015 11:14 |
>Например, как работать с ini файлом в utf-8 В SynCommons есть соответствующие функции. Там вообще много чего есть. >Но можешь попробовать в отдельной ветке. Спасибо за разрешение, но нет. |
(0016684) vdemidov (manager) 02-11-2015 11:21 |
>>Но можешь попробовать в отдельной ветке. >Спасибо за разрешение, но нет. Жаль. Было бы интересно посмотреть что из этого выйдет. |
(0017325) vdemidov (manager) 10-06-2016 07:40 |
Учитывая последние изменения в билд системе, похоже, что эту хотелку можно закрывать как выполненную? |
(0017333) zed (manager) 10-06-2016 17:31 |
Да. |
Users who viewed this issue | |
User List | Anonymous (10232x), looo (4x), vdemidov (88x), eduard_m (3x), ygorigor (3x), Garl (2x), zed (33x), cycler (1x), dkxce (2x), Tolik (2x), netsky (1x), aflexus (1x), Fed (57x), sheavy (1x), bk99 (2x), vasketsov (2x), GunSmoker (5x), gma (1x) |
Total Views | 10440 |
Last View | 21-11-2024 12:30 |
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 | View Revisions |
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 | View Revisions |
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 | 26xxxx => 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 |
My View | View Issues | Change Log | Roadmap | Search |
Copyright © 2007 - 2024 SAS.Planet Team |