|
Notes |
|
|
|
|
|
|
|
|
Да хоть XE5. У меня XE2 установлена. А какую Zed на сервер для сборки поставит та и будет, я не думаю, что там принципиальная разница будет. |
|
|
|
|
|
Под XE4 проект не собирается капитально, юниты надо именовать с префиксами. Если нет желания перелопачивать всё и вся - значит XE2. |
|
|
|
|
|
Ну тебе виднее. Я не пробовал. Но переход на юникод нужен однозначно. |
|
|
|
|
Я ставил XE4 чтобы оттуда свистнуть файлы для Sensor API (и ещё несколько зависимых, которых в XE2 нет). Но даже после правки имён юнитов просто так их заюзать в XE2 не вышло из-за delayed. Сделал вывод, что переход 2007 -> XEn для n>2 слишком сложен для одновременной поддержки обоих компиляторов.
Возможно где-то конечно и недодумал.
Также для GR32 (или чего-то такого столь же важного) нет поддержки XE4. |
|
|
|
(0014605)
|
|
zed
|
|
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. |
|
|
|
|
Ну так давай, хотя, это несколько расходится с моими мыслями о переходе везде на 2-х байтный юникод, что бы потом в интерфейсах использовать WideString с меньшими расходами, но это такое отдаленное будущее, что бог с ним...
Мне честно говоря очень не хватает новых плюшек делфи. |
|
|
|
(0014609)
|
|
zed
|
|
04-09-2014 19:13
|
|
>использовать WideString
Это тип строк работает убийственно медленно. Их вообще не стоит использовать без острой необходимости. Лучше старый добрый PAnsiChar, через который и utf-8 прекрасно передаётся. |
|
|
|
|
> Это тип строк работает убийственно медленно.
За все нужно платить. Зато эти строки можно передавать в dll на любом языке скомпилированную в любом компиляторе и обратно без малейших проблем. А это для интерфейсов достаточно важно.
Но я же говорю, что это не существенно и не предлагаю так делать.
И вообще я за скорейший переход на более свежую версию делфи. |
|
|
|
|
|
Какие у нас остались проблемы с переходом на юникодную версию делфи кроме регекспов? |
|
|
|
(0015616)
|
|
zed
|
|
20-04-2015 07:54
|
|
А что с регэкспами? Там же widestrig под юникодом. Медленно, но надежно.
Думаю, можно выпускать юникодную сборку для тестов и звать китайцев, чтобы они нас багрепортами забросали. Тогда будет более-менее понятно. |
|
|
|
|
А парсеры и читалки уже умеют отличать буфер и файл с диска соответственно, юникодный он или нет?
А сохранять файлы всегда в юникоде будете? |
|
|
|
|
|
Об этом и вопрос. В большинстве мест там уже есть определение типа текстовых файлов. Но везде ли оно правильно сделано? |
|
|
|
|
>В большинстве мест там уже есть определение типа текстовых файлов
Хм. Видимо мы друг друга не очень понимаем. Но мне кажется, что про большинство мест ты несколько погорячился.
Возьмём для примера файл mp (польский формат).
Он может быть не юникодный, но в заголовке указана кодировка.
Я не помню такого куска кода, который бы это нюхал и конвертировал в юникод или текущую кодировку, а без этого что-то искать в общем случае бессмысленно.
И в принципе я поднимал вопрос с определением того, вот конкретно взятый буфер с текстом юникодный или нет, интереса оно у вас не вызвало. А между тем это первое, что надо делать после чтения любого файла, если мы хотим с ним работать как с текстом. У меня есть такой пример в коде внутреннего httpd.
Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?
Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.
У HashFunction есть расчёт хэша по WideString? Нет. А между тем, где оно будет форсироваться после проверки, оно должно быть.
Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
В принципе по каждому сохраняемому типу файлов надо понимать, в каком виде надо уметь их сохранять. Потому что если потом встать в позу, что мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая. Это касается привязок, экспортов и т.п. Даже там, где нет юникода, может прокатить AnsiString и прямое указние кодировки, но перекодировка обязана возникнуть, а сейчас её нет.
Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.
Это только то что я помню сходу. Но даже этого достаточно. |
|
|
|
|
>Возьмём для примера файл mp (польский формат).
>Он может быть не юникодный, но в заголовке указана кодировка.
Основной вопрос станет ли он работать хуже чем работает сейчас сейчас там используется TStringList.LoadFromStream(VDataStream) вот и нужно смотреть что оно там в новой делфи загрузит.
> Тайл векторный внезапно прилетит юникодный - залетит в хранилище, а потом нормально поднимется из хранилища и покажется?
Для kml/kmz есть определения кодировки, так что тут проблем нет.
> Сохранение тайла должно быть в том же виде, как он был при чтении (например, настроек), это есть? Нет.
У нас вообще нет сохранения векторных тайлов кроме конвертации kml<->kmz, но там проблема не возникает, как и для сохранения растров.
> У HashFunction есть расчёт хэша по WideString?
Там есть расчет хэша по текущему типу строк, его более чем достаточно.
> Экспортилка меток на alcinoe ансишная - форсировать UTF8 и надеяться, что всех китайцев это устроит? ))) SML тоже UTF8 ЕМНИП.
Что тебя тут не устраивает?
> мы сохраняем файл как юникод, а то что следующая программа в рабочей цепочке его не понимает или устройство его не принимает это не наши проблемы, поза будет внезапно очень глупая
Увы, но я это переделывать буду, только если сам столкнусь с такой проблемой или за отдельные деньги, а до тех пор юникод наше все.
>Также ЕМНИП была проблема с текстом в IInternalDomainInfoProvider сотоварищи: contenttype описан как AnsiString, а в провайдерах String. Хотя конкретно это может и мелочь.
Ну, не считая импорта mp (тупого и такого наколенно-ущербного что дальше некуда) это первая реальная проблема о которой ты напомнил, но о ней напоминает и компилятор.
> Это только то что я помню сходу. Но даже этого достаточно.
Итого - ничего серьезного. Можно пробовать делать ночные сборки. Спасибо что успокоил. |
|
|
|
(0015623)
|
|
vasketsov
|
20-04-2015 15:27
(edited on: 20-04-2015 15:28) |
|
>TStringList.LoadFromStream ... нужно смотреть что оно там в новой делфи загрузит
А посмореть никак что ли? )))
Хотя куда более интересно, что оно сохранит, и как потом быть, если надо запустить старую версию саса.
>У нас вообще нет сохранения векторных тайлов
Уважаемый, Вы невнимательны. Речь была не о векторных тайлах, а о файлах вообще. Пример - настройки. В нужной пользователю кодировке.
>Что тебя тут не устраивает?
В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))
>но я это переделывать буду, только если сам столкнусь с такой проблемой
Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе? В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.
|
|
|
|
|
> А посмореть никак что ли? )))
Увы, на работе делфи нету, так что никак.
> Речь была не о векторных тайлах, а о файлах вообще.
Файлы вообще нас не интересуют. Нас интересуют текстовые файлы. Причем каждый конкретный тип сохраняемых данных требует своего подхода: некоторые форматы подразумевают юникод и уже сейчас сохраняются в UTF8, некоторые допускают только Ansi и соответственно уже сейчас там прописано использование AnsiString и следовательно будет работать как и сейчас. А некоторые типа ини-файлов разницы никакой лишь бы работало. Поэтому нужно говорить о конкретных файлах, а не в общем.
> В Ansi-шном экспорте меток надо китайцев спрашивать, что их не устроит. Меня устраивает cp1251 может быть ))
Хуже чем сейчас не будет, это факт.
>Ну так значит кинешь всех, у кого такие проблемы будут, или zed будет вынужден собирать старые сборки в 2007 дельфе?
И чем это их спасет? Но в общем и целом никто пока не призывает совсем отказываться от сборки в 2007 делфе. Речь о начале сборки в новой.
> В принципе, я такой позицией не удивлён, просто акцентирую на этом внимание.
Странно. Почему не удивлен. Я ведь эту позицию, что я никому ничем не обязан и это опенсорс, озвучивал всего пару десятков раз. |
|
|
|
|
> чем это их спасет?
файлы будут неюникодные.
>некоторые типа ини-файлов разницы никакой
Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?
>Речь о начале сборки в новой
Разве?
Читаю в заголовке: "Переход на версию Delphi с полной поддержкой юникода".
Мы о разному понимаем слово "Переход"?
Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.
>Речь о начале сборки в новой
Не вижу связи между словои "Переход" и словосочетанием "начале сборки в новой".
Ты именно предлагаешь ночнушки начать собирать в XE2 и только в этой версии?
Так это вообще не переход. Это даже не запах его на горизонте. Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется. |
|
|
|
|
> файлы будут неюникодные.
Какие конкретно и что это им даст?
> Совместимость с предыдущей версией и одновременная работа из одной папки двух разных сборок не требуется?
Нужно проверять конкретные места и если не работает заводить отдельные инциденты. Но ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси, а писать в своем родном формате.
>Одновременная временная поддержка двух версий среды разработки - совершенно не "Переход", но лишь его ранняя предвестница.
Ну, это часть перехода. И ИМХО таки уже пора.
>Тем более что мне казалось, что сборка в XE2 уже выполняется и даже публикуется.
Когда кажется - креститься нужно. |
|
|
|
|
>ИМХО для этого достаточно что бы каждая версия могла читать юникод и анси
Это минимум, без которого говорить о переходе более чем наивно.
Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате? |
|
|
|
|
> Сейчас ini и паскальскрипты в zmp читаются корректно в любом формате?
Вот, наконец, хоть какая-то польза из этого переливания из пустого в порожнее. Нужно проверить как юникодная версия сохраняет конфиги и читает их.
Zed, можешь сбилдить XE2 версию? А еще лучше было бы сделать хотя бы еженедельную сборку дебажной XE2 версии. |
|
|
|
|
>Вот, наконец, хоть какая-то польза
Ты издеваешься?
Ещё вчера в первом же сообщении я написал про "читалки" файлов. Потом конкретно уточнил "например, настроек" - ты это прочитал вообще, или просто по диагонали?
Если тебе кажется, что я излишне прямолинеен - это не повод не читать, что тебе пишут. Особенно когда в написанном содержится ответ на вопрос. Тогда бы и "переливания" удалось избежать.
>проверить как юникодная версия сохраняет конфиги и читает их
А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты. А поскольку ini-шки у нас правятся в том числе руками, для проверки этого не обязательно собирать U-версию и забирать из-под неё ini-шки, достаточно обычного блокнота. И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный.
>еженедельную
Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.
А каких именно "новых плюшек делфи" не хватает, кроме юникода? |
|
|
|
|
>Ещё вчера в первом же сообщении я написал про "читалки" файлов.
Это общий свист ни о чем. Конкретное предложение это добавить чтение юникодных конфигов в текущую версию. Сейчас создам отдельный инцидент.
>А ещё нужно проверить, как неюникодная версия поднимет юникодные ini-шки и скрипты.
Только ini-шки. Скрипты пока будут жить в виде Ansi - для генерации урлов этого более чем достаточно.
> И я так уже делал. Результат не самый приятный, но в какой-то степени очевидный.
Вот и нужно было об этом написать.
> Зачем? Еженедельно можно старую версию собирать. Если озабочены переходом - собирать новую надо ежедневно. При случае всегда можно откатиться на старую не более чем недельную.
Ну, это если есть возможность. А на первое время хотя бы раз в неделю.
> А каких именно "новых плюшек делфи" не хватает, кроме юникода?
Ну лично мне, не хватает дженериков. Плюс некоторые плюшки самой среды разработки. |
|
|
|
(0015633)
|
|
zed
|
|
21-04-2015 16:15
|
|
Периодически собираю для себя юникодную версию и запускаю прямо из рабочего каталога неюникодной версии, а потом наоборот, запускаю неюникодную. Соответственно, ни в той, ни в другой версии проблем с ini, zmp, метками и кэшем Беркли не наблюдаю. Настройки как хранились в win1251, так и хранятся.
По поводу билдов XE2, у меня есть задумка доделать автоматическое обновление SAS и добавить канал обновлений Nightly Unicode, чтобы все желающие могли тестировать. Соответственно, и билды в тот канал будут заливаться одновременно с билдами обычной ночнушки.
Ну и наконец, по поводу "плюшек" новых делфи. Лично я за то, чтобы в коде сохранялась совместимость с D2007. |
|
|
|
(0015634)
|
|
vasketsov
|
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;
|
|
|
|
|
> Очень тяжело себя сдерживать.
Именно
> Настройки как хранились в win1251, так и хранятся.
C одной стороны хорошо тем, что две версии работают без усилий.
Но тогда получается будут потери данных в юникоднрой версии. Так что хотелку 0002690 стоит реализовать. |
|
|
|
(0015638)
|
|
zed
|
|
21-04-2015 19:05
|
|
>Очень тяжело себя сдерживать
Сдерживались же до этого, и вроде все живы.
В новых компиляторах много сюрпризов может быть: http://alexander-bagel.blogspot.com/2015/04/8.html В идеале, если и менять компилятор, то на самый стабильный. Кто готов назвать такой в ветке XE? Сама по себе XE2 уже устарела (выпощена в 2011 году). А с более новыми версиями (к примеру, если замахнуться на XE8), боюсь у нас с Toolbar2000 и EmbeddedWB будут проблемы. |
|
|
|
|
>Кто готов назвать такой в ветке XE?
По отзывам - как раз XE8 )))
>XE2 уже устарела
Переход на XEn, где n>2, вызывает сомнения.
В частности, на XE4 проект не собирается из-за префиксов, см. выше в теме.
Имхуется, что XE2 - необходимое зло, то самое, которое надо минимизировать, и без которого (перехода на которое) никак не двинуться дальше.
>EmbeddedWB
В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много. |
|
|
|
|
Сохранил GetUrlScript.txt в юникоде и открыл в супер-zed-отладчике - вот так он выглядит:
яюv
дальше визуально читаемый текст через пробелы, в реальности нулевые символы, поэтому даже не копируется.
Собственно, поведение вполне ожидаемое, что и было написано выше.
Конкретно за паскальскрипты - это будете фиксить, или просто надо будет анонсировать, что скрипты не юникодные? |
|
|
|
|
Там же вдогонку: если скрипт был в UTF8, то читается он как Ansi:
п»їvar res:string;
i:byte;
osX,osY,prX,prY:integer;
begin
res:=''; // проверка |
|
|
|
|
|
Хинты в главном меню отображаются знаками вопроса |
|
|
|
(0015646)
|
|
zed
|
|
22-04-2015 06:04
|
|
>В SACS его нет уже очень давно. Выпиливается легко, пользы от выпиливания много.
А Toolbar2000 тоже предлагаешь выпилить? |
|
|
|
|
>Toolbar2000
Успеют, с нашей-то скоростью ))) |
|
|
|
(0015662)
|
|
zed
|
|
22-04-2015 10:47
|
|
|
Куда там. Судя по всему, мёртв он давно. |
|
|
|
|
|
Упс. Ну тогда будем решать по факту. Допиливать по месту или искать аналоги/замену. |
|
|
|
|
|
Ну нам нужно искать замену не Toolbar2000, а TBX, а для него есть аналог SpTBX |
|
|
|
|
На 2010-й дельфе пробовали пускать проект?
Я пожалуй откажусь от сборки под 2007, а то что-то какие-то косяки при установке 2007 на новую ось на ноуте. Версии 2010 и XE2 оставлю. Не ради новых фич, а просто жаль время разбираться, фичи пока подождут. |
|
|
|
(0015740)
|
|
zed
|
|
25-04-2015 10:19
|
|
|
А смысл? Там же тот же юникод. Тогда уж переходи на XE2 сразу. |
|
|
|
|
|
Так XE2 и так на соседнем разделе есть. 2010 для других проектов надо поставить. |
|
|
|
|
> "Под XE4 проект не собирается капитально, юниты надо именовать с префиксами."
Достаточно в опции проекта вписать нужные namespace. |
|
|
|
|
|
Предлагаю начинать выпускать ночные версии собранные в XE2. Это пока еще не даст нам полную поддержку юникода, но хотя бы позволит убедится, что юникодная версия работает не хуже собранной в D2007. |
|
|
|
(0016628)
|
|
zed
|
|
26-10-2015 12:15
|
|
|
В дополнение к D2007 или вместо? |
|
|
|
|
|
Ну, на первое время, конечно, в дополнение. А там посмотрим по количеству багов и отзывов. Если будет слишком мало, то и вместо. Но вообще смотри по возможностям твоего билд сервера :) Как решишь так и будет. |
|
|
|
(0016632)
|
|
zed
|
|
26-10-2015 17:33
|
|
|
|
|
|
|
Спасибо большое. Пока пусть втихую появляется. А потом сделаем объявление с просьбой активнее тестировать. |
|
|
|
|
|
В общем, после того как соберется сегодняшняя ночная версия, я не вижу никаких препятствий для объявления о тестировании юникодной версии. |
|
|
|
(0016645)
|
|
zed
|
|
28-10-2015 20:00
|
|
|
Да, можешь анонсировать. Хотя, сомневаюсь, что народ сильно заинтересуется. |
|
|
|
|
Заглянул в модуль 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. Как она хавает юникодные строки я не понимаю. |
|
|
|
(0016653)
|
|
zed
|
|
30-10-2015 10:14
|
|
А 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;
|
|
|
|
(0016654)
|
|
zed
|
|
30-10-2015 10:15
|
|
|
Но можно и пофиксить, для надёжности. |
|
|
|
|
|
Понятно. Это была настолько популярная бага, что для нее сделали костыль. Думаю лучше пофиксить для беркли и пнг |
|
|
|
(0016677)
|
|
zed
|
|
01-11-2015 10:53
|
|
|
|
|
|
|
Решение крутейшее, но не для делфи, где почти все компоненты и инструменты заточены на работу с юникодом. Например, как работать с ini файлом в utf-8 без полной перекодировки его в utf-16, если стандартный компонент для работы с ini-файлами в юникодной делфи работает только в utf-16. Но можешь попробовать в отдельной ветке. |
|
|
|
(0016683)
|
|
zed
|
|
02-11-2015 11:14
|
|
>Например, как работать с ini файлом в utf-8
В SynCommons есть соответствующие функции. Там вообще много чего есть.
>Но можешь попробовать в отдельной ветке.
Спасибо за разрешение, но нет. |
|
|
|
|
>>Но можешь попробовать в отдельной ветке.
>Спасибо за разрешение, но нет.
Жаль. Было бы интересно посмотреть что из этого выйдет. |
|
|
|
|
|
Учитывая последние изменения в билд системе, похоже, что эту хотелку можно закрывать как выполненную? |
|
|
|
(0017333)
|
|
zed
|
|
10-06-2016 17:31
|
|
|