Кто-нить работал? А то я подключил сам 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 :)

2 SPeller
Слушай, а где у тебя косяки в 2009 вылазят? Я щас совершенно спокойно с UNICODE_CTRLS откомпилил свой проект...

SPeller, в КОЛе есть способ как в один инк засунуть и описание и реализацию.

Вообще считаю что нет смысла разбивать на файлы КОЛВин, колфайлс.... и т.д. И плодить инки тоже не стоит, я бы наоборот большую часть инков убрал бы и внёс в сам КОЛ.пас.

И я бы внёс обратно, но вспоминаем ограничение на 64К строк. Дальше возникают проблемы с отладчиком в Delphi. Или речь об inc-ах в проекте MCK? Там тоже далеко не всё можно. Есть такие хитрые inc-файлы, которые изначально нужны для обмана Delphi IDE, чтобы он в дизайнере "думал", что имеет дело с классом VCL, и мог работать с формой. Если их засунуть в сам файл, Delphi скажет, что это не юнит с формой. Вообще, не знаю каким чудом удалось получить такой результат. Можно сказать, это - эксплоит в Delphi.

> Можно сказать, это - эксплоит в Delphi.
8) +1

> Я щас совершенно спокойно с UNICODE_CTRLS откомпилил свой
> проект

Я тожа откомпилил. Ты ворнинги посчитай, и посчитай места, где юникод в анси преобразуется. В таких местах текст, не соответствующий локали, превращается в вопросики. Кроме того, надо понимать, что при любом преобразовании компилятор, где может, вставляет соответствующие вызовы функций. А это не может играть в сторону снижения объема конечного бинарника и в сторону увеличения быстродействия.

> в КОЛе есть способ как в один инк засунуть и описание и
> реализацию

{$IFNDEF func_impl}
declaration
{$ELSE}
implementation
{$ENDIF}

?

Все. Понял про что ты... В принципе, такие ворнинги должны были и других версиях быть. Просто не соответствие типов, типа Str2Extended получает AnsiString, а в функции используется CopyEnd c KOLString в параметре. При UNICODE_CTRLS, соответственно лажа. Несоответствие типов и возможность утери данных...

Там работы "вагон и большая телега"...надо очень много править. Возможно пересмотреть политику использования A и W функций, чтобы доступ был к обоим вариантам, а по директиве выбирался нужный (если то необходимо)...

SPeller, смотри KOL_unicode.inc и как он подключен:

 {$DEFINE interface_part} {$I KOL_unicode.inc} {$UNDEF interface_part}

.....

  {$DEFINE implementation_part} {$I KOL_unicode.inc} {$UNDEF implementation_part}

Vladimir Kladov, да я в курсе) причем со временем "эксплойт" получилось заточить под новые версии))

Я просто высказывал то "что хотелось бы", но это не инструкция к действию

2 Speller
В общем, самый простой вариант решения проблемы (компилятор перестает ругаться) такой.
Сейчас:


Ошибка:



Правка:


Ошибок нет.

Кстати, заметил вот еще какую фишку...не знаю, может это только у меня в проекте. При использовании D2009 директива UNICODE_CTRLS, установленная для проекта, !!!игнорируется!!! в KOL.PAS. Первой строчкой пришлось дописать:

Кстати, вот еще что. В свое время, для TDirList.ScanDirectory мной был предложен код проверки на unicode символы:


не знаю почему сразу это не сделал, но для себя ввел еще дополнительно одну директиву. Сейчас код такой:


Чтобы пользователь сам мог выбирать с какими именами работать, благо оба варианта работают нормально...

> Там работы "вагон и большая телега"...надо очень много править

Ага. Я потихоньку для себя делаю )


> чтобы доступ был к обоим вариантам, а по директиве выбирался
> нужный (если то необходимо).

Я тоже пришел к такому выводу относительно функций управления строками (strlen, strcmp и т.п.). А вот функции вроде Trim и Int2Str - это стопудово только KOLString.


> D[u]fa   (31.03.09 11:53) [27]

Я не смотрел, но так и подумал.


> При использовании D2009 директива UNICODE_CTRLS, установленная
> для проекта, !!!игнорируется!!! в KOL.PAS

У меня не игнорировалась. Но я у себя для д2009 прописал принудительную установку этой директивы.

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

Ну вот, скомпилилось. 17408 размер, без системных замен, разумеется. Теперь баги вычесывать :)

под Ini-файлы надо свой парсер писать. Хоть и используется WritePrivateProfileStringW, в файл пишется ansi.

2 SPeller
Поделишься?

> под Ini-файлы надо свой парсер писать. Хоть и используется
> WritePrivateProfileStringW, в файл пишется ansi.

Я для winCE делал аналог PIniFile. Вернее он "инклудится" в KOL.pas и заменяет родной. Основан на StrList. Правда работает именно как ANSI, но думаю поправить под WideString не сдожно будет.

PS. Взять можно в KOL для Lazarus'a от Юрия Сидорова.

Кстати, напомните, отчего нигде overload не используется в kol?


> Поделишься?

Попричесываю немного и поделюсь

> без системных замен

но с прописанным в uses переделанным variants.pas )

блин, вот наврал-то... без вариантов
:)

> Я для winCE делал аналог PIniFile

Посмотрел. Под юникод портировать не должно быть проблем. Можно опиционально сделать сохранение в utf8

У меня вопрос ко Владимиру: почему в kol не используется перегрузка функций?

И еще думаю оставлять ли совместимость с предыдущими версиями, или ножом всё лишнее и оставить только необходимое для д2009? Есть установленная д6, могу на ней тестить.

> И еще думаю оставлять ли совместимость с предыдущими версиями,
>  или ножом всё лишнее и оставить только необходимое для
> д2009? Есть установленная д6, могу на ней тестить.
Ну уж думаю не стоит так круто... Не думаю, что 2009 - это панацея от всех бед программера... Апдейты выходят с завидным постоянством, кривость ИДЕ и компилятора наблюдается невооруженным глазом (особенно в юникод-проектах)...зачем же рубить с плеча.

Ну, глюки конечно есть, но они по большей части касаются юзабилити. На небольших проектах обкатываю - работает как часы. Глюков компилятора видел пару, но они не критичны. Надеюсь что 3-й апдейт попричёсаннее получится.

Вот последняя капля (для меня), которая утопила D2009. Скомпиленный ЕХЕшник в Win98 не работает... Т.ч. пока проект требует поддержки Win9x/ME, D2009 "курит в сторонке"...

кто-то еще использует вин98?

> кто-то еще использует вин98?
По всей вероятности - да... В крайнем случае, запрос на ANSI-версию для использования в Windows 98 (а пару раз и 95ую "поминули"), приходят с завидным постоянством...

Перегрузка не поддерживается в Delphi2, Delphi3. Насчёт Delphi4 не помню, но она как раз не очень нужна.

Ясно.


> но она как раз не очень нужна.

Она очень нужна для функций вроде StrLen. Чтобы не плодить клонов с префиксами/постфиксами.


> По всей вероятности - да

Значит надо поковырять и найти причину )

> Значит надо поковырять и найти причину )
Причина уже найдена...и следствия тоже: http://www.sql.ru/forum/actualthread.aspx?tid=649563
Но ковырять системные ПАС-файлы ради D2009 я не собираюсь. Мне и с 2007 нормально работается 8)

я имел в виду Delphi4 а не перегрузку. Да и перегрузка тоже не самое необходимое.