Кто-нить работал? А то я подключил сам kol, компилируется после небольшой доработки напильником, но такую тучу ворнингов выдет относительно строковых преобразований, что мама не горюй. Были пару
опасных, но не помню уже где - поправил. Есть и замечания/вопросы:

- Что за ерунда с KOLString/KOLChar? Половина функций работает с KOLChar, половина нет, только с AnsiString, в результате те, что только AnsiString, не могут корректно работать с родными дельфийскими юникодными строками.
- Для некоторых функций определены юникодные аналоги с префиксом W. Но не все. Это они просто никому небыли еще нужны, или есть тайный смысл?
- В чем смысл когда одни функции работают с KOLString и когда другие вместо этого обретают сестер с префиксом W? Почему небыло выбрано одной стратегии?
- Есть желание заменить WideString/WideChar на string и Char, на родные дельфийские типы, как рекомендуют авторы. Вводить еще один тип KOLWideString? А то неохота при нативной поддержке юникода мешать родной тип строк с ком-строками.

Вобщем, зарылся тут с этим, в голове каша, боюсь старый добрый KOL юзать :)

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

Почему завел эту тему - потому что решил перейти на сабжевую версию. По скорости работы IDE вполне устраивает, новые фичи, хоть местами и глючные. Главное что юникод. Поднял старый свой "for fun" проект на kol и решил его реанимировать. Поэтому хочется чтобы KOL мог правильно тут работать, раз уж он у нас всеядный к версиям дельфей. Изменения я конечно могу повносить через find/replace, но вот тестить всё не смогу. Скооперироваться бы с кем-нить, кто тоже работает с 2009. Да с идеологией разобраться. Владимир, по вопросам выше отпишитесь пожалуйста.

Привет...

Встречный вопрос, а почему 2009? Почему не 2007? Пробовал перейти на 2009, но уперся в грабли с настройками CodePage для всего проекта. 2007, тоже очень сносно держит юникоде...а больше особых преимуществ в 2009 я не заметил...

З.Ы. Может немного не в тему, но KOL давно надо пересмотреть и подчистить. По мне, если Владимир соберется, лучше использовать модульность.
Если строковые функции, то в отдельный файл, графика (bitmap, icon) - в отдельный файл, потоки - тоже...а то слишком уж все намешано...и мухи, и котлеты. Некоторые условные компиляции непонятно зачем вообще нужны. Некоторые код, Visual XP themes, например, присутствует в KOL.PAS, но никогда не используется...используется аддон...

З.З.Ы. Не согласен с exero: http://pda.delphimaster.net/?id=1238063198&n=10, KOL - очень серьезный проект, его уникальность именно в том, что он, пожалуй, единственный в котором есть логика, на Паскале. Есть еще Lenin Inc WinAPI, однако отсутствие возможности дизайнтайм разработки, на корню отбивает желание использовать его...хотя должен признать, что некоторые код использую оттуда...

ВСЕ ВЫШЕСКАЗАННОЕ ЛИШЬ МОЕ ИМХО. Никого ни в чем убеждать не хочу и не буду.

С Уважением, MTsv DN

> а почему 2009? Почему не 2007?

2007 намного глючнее IDE, медленнее. Вообще, юникод еще давно был, как WideString, а вот именно нативная его поддержка компилятором - это другое.


> но уперся в грабли с настройками CodePage для всего проекта

Мы тут на работе перетаскиваем большой проект на 2009. Скомпилился почти сходу, поправить пришлось пару строк. Заработал. Единственное что-то там с экселем были небольшие проблемы, но я в это пока не углублялся.


> KOL давно надо пересмотреть и подчистить. По мне, если Владимир
> соберется, лучше использовать модульность

Согласен. Не только подчистить, но и причесать. Модульность - можно, но только очень небольшую, т.к. россыпь файлов тоже не есть хорошо.

Не надо бить на части. Префикс W для работы с unicode в обчном прилодении.

Я лишь высказал свое мнение. Никто и не призывает дробить KOL.PAS на кучку маленьких юнитов.

Однако, должен с Вами, Владимир, не согласиться. В KOL.PAS черт ногу сломит, все в одном файле: и импорты некоторых функций, и некоторые константы, и работа со строками, и создание контролов, и функции отладки, и прочее, и прочее, и прочее.....перечислять можно уйму времени. Пришлось же выкинуть часть кода в KOLadd.PAS, а почему бы все не систематизировать? Я ж не предлагаю, что-то невообразимое. Это же никак не отобразиться на размере программы...

> Префикс W для работы с unicode в обчном прилодении

Зато когда мы переключаемся в UNICODE_CTRLS, тот же Trim существует только для ansi и русский текст на аглицкой винде мы потеряем.

Тут мне кажется либо что-то хорошо причесывать, либо забыть про KOL на д2009, т.к. некоторые даже самые простые функции не имеют юникодного исполнения, хотя, по идее, всё что работало со string, должно автоматически стать UnicodeString.

Хотя, остается вариант сделать версию для себя и так и сидеть на ней, если затея наведения порядка не встретит поддержки.

Владимир, вы бы написали свои соображения по существу. А то как-то даже кажется что вам всё-равно.

SPeller, лучше забудь..

D[u]fa
Да ладно, тебе. Меня тоже интересует, что Владимир думает. Какие у него планы по поводу будущего KOL'а.

Я уже писал почему. +до 100 байт на каждый модуль, даже если он ничего не содержит. KOL для экстремально малых микроутилит. Я зря, что ли, добивался, чтобы минимальное пустое приложение оказывалось 11.5К. Не было бы ограничений на 64К строк в исходнике, я бы и большуя часть KOLadd оставил в KOL.pas с удовольствием.

Я в общем-то, несколько ошарашен... Что Вы готовы пожертвовать удобством программирования за 100 байт... Ребилд ехе-шника, плюс сжатие UPX-LZMA компенсирует это на "раз-два-три"... Ну, ладно... Здесь я Вашу позицию понял...

Владимир, а можно все же услышать ответ на вопрос:
Какие у Вас планы по поводу будущего KOL'а?

Удобство программирования - это VCL/CLX. А на сколько модулей вы хотите разбить KOL.pas? Умножить 100 на это количество не забудьте. Притом, что я вобще не понимаю, каким образом удобство программирования связано с количеством модулей, на которые разбит модуль KOL.pas. Опишите преимущества, пожалуйста. В чём они заключаются?

Не слишком большое, максимум 5-6... Я уже говорил о том, что по моему мнению, надо вынести отдельно...

А преимущества, очевидны. Удобнее работать когда все систематизировано, и находится там где ожидаешь, а не все в одной куче...

Кстати, Вы так и не ответили на более Глобальный Вопрос...

Тут нужно придумать хитрую штуку. Чтобы и на старых дельфях микроутилиты не выросли, и чтобы на новых небыло затруднений.
Есть один грубый путь, который есть всегда - послать всех лесом и сделать так, чтобы было правильно с идеологической точки зрения. Но, на сколько я помню историю KOL, такое исключено. Можно попытаться унифицировать функции rtl так, чтобы они работали везде так, как от них ожидают на каждой версии дельфей. Объекты с префиксами W - ладно, пусть придется переправить свои исходники. Но вот править вызовы обычных стандартных функций - это уже бред, имхо.
Тут появляется две строны, тянущие один канат в разные стороны: те, кто изначально ansi, но хотят работать с юникодом в отдельных местах, и те, кто изначально юникод, и хотят чтобы их данные нигде не потерялись. Первые хотят появления сестер с префиксом W, а другие хотят унификации в виде KOLString/KOLWideString и плясок от количества байт в символе. Вот тут мне и представляется основная проблема. Как и волков сытыми оставить, и овец сохранить.

Плка всё и так хорошо. Есть отдельная версия для WinCE. Разве оно плохо, что она немного отличается? Другое дело, если туда что-то добавлено кардинально полезное, что могло бы пригодиться в Windows-версии. Предлагайте код, вставим.

Можно сделать аналогично параллельную версию для линукса. Я так начинал для GTK+, но некогда стало заканчивать. Да и не линуксоид я, максимум, что смогу проверить - что оно компилируется под windows и работает с версией GTK+forWindows.

Похоже, это и есть оптимальный путь. Хотя и требует дополнительных усилий по синхронизации.

А делить на версии: мне не очевидно, в чём преимущество дробления исходного файла на 6 частей. Если с точки зрения использования KOL, так гораздо проще один раз в uses иметь ссылку на KOL, чем отдельно на KOLwindows, KOLfiles, KOLregistry, KOLmain, KOLadd, KOLxyz и т.п. Если с точки зрения разработчика KOL, так гораздо проще и удобнее всё находить в одном файле, чем рыться по целой директории. Так что мне очевидней, что одним файлом удобнее.

а разве нельзя так:

unit KOL;
{$I kolstrings.inc}
{$I kolthreads.inc}
[...]
end.

а для отдельных случаев
unit KOLStrings;
{$I kolstringsd.inc}
end.

в экзотических случаях даже может меньше получится, наверное :)

> а разве нельзя так:

Можно, но не удобно прыгать по Ctrl+Up/Down с описания на реализацию. Кроме того, в один .inc не засунешь описание и реализацию, на два надо бить. Я так уже вычёсывал объявления функций, сначала в inc, потом в конец интерфейсной части. Чтобы в одном месте все были все функции. Получилось, но где-то посеял директиву компилятора и теперь на непонятной строке выскакивает Unterminated conditional directive :)