> I suggest maybe a more generic switch like TARGET_EXE or
> TARGET_DLL would help for these cases?

I did not found how to determine which type of binary is producing in conditional symbols. If there is some way to do it - it should be used.

Проблема: при сипользовании USE_MHTOOLTIP KOL не компилируется.

Проблема: при использовании USE_GRAPHCTLS вываливается экзепшин при отрисовке в PaintGraphicChildren из-за мусора, возвращаемого TControl.GetChildCount.

ЗЫ: Всегда использую PAS_VERSION
ЗЫ: Версия U

проблема: Не грузится в KOLImageShow фрагмент изображения BITMAP_0 из файла ресурса (*.res)

ImageList1.LoadBitmap('BITMAP_0',clWhite);
ImageShow1.CurIndex:=0; ImageShow2.CurIndex:=1;

Для Д2009 и выше нужно добавить:




Это копипаст решения из сисутилс для случаев проверки string[n] in set. Поскольку set остался set of ansichar, а символы в string стали widechar - дельфи выдает ворнинг, типа, используйте CharInSet из SysUtils. Со вводом юникода они отметили ворнингами все места, где происходит неявное преобразование чего-либо касающегося строк и где может произойти потеря информации или данный код нужно переработать чтобы преобразования не было. И отсутствие ворнингов для меня правило хорошего тона при написании кода )

Другие изменения для д2009 и выше (версия U):

visual_xp_styles.inc:
682:  S : KOLString;

kol.pas:
10198: function NewGraphLabel( AParent: PControl; const ACaption: KOLString ): PControl;

11259: function Num2Bytes( Value : Double ) : KOLString;

11278: function cHex2Int( const Value : KOLString) : Integer;

11280: function Octal2Int( const Value: KOLString ) : Integer;

11546: function StrIn( const S : AnsiString; const A : array of AnsiString ) : Boolean;

соответствующие изменения заголовков функций в разделе реализации опущу

20227:     if Value[ I ] in [ '0'..'7' ] then
to
   {$IFDEF _D2009orHigher}
   if CharInSet(Value[I], ['0'..'7']) then
   {$ELSE}
   if Value[ I ] in [ '0'..'7' ] then
   {$ENDIF}

20346:   if {$IFDEF UNICODE_CTRLS}WAnsiEq{$ELSE}StrEq{$ENDIF}( Copy( Value, 1, 2 ), '0x' ) then

при сипользовании USE_MHTOOLTIP KOL не компилируется.




Не пойму в каком Delphi, в 2010 компилируется, см. Версия V.

На сайте версия 3.00.W, исправления для Graph_ctls и ImgShow (asm).

2Speller
У нас есть WInChar, если кому нужен, и он появился до того, как в Delphi добавили CharInSet. Другое дело, что где-то по-прежнему может использоваться in [ ]. Но я вычищал все предупреждения, заменяя максимально эффективным >= and <=. Или говорите, где (при каких условиях) лезут ворнинги.

Лучше не изменения давайте, а командную строку для компиляции, чтобы те же предупреждения (или ошибки) выскочили.

> Другое дело, что где-то по-прежнему может использоваться
> in [ ]

Вот оно и используется в строке 20227, функция Octal2Int.


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

Попробую. Но предыдущие изменения и так понятны, последнее - это функция cHex2Int.


> Не пойму в каком Delphi, в 2010 компилируется, см. Версия
> V.

Добавьте к своей строке -DDEBUG. В релизной версии у меня тоже компилируется, как оказалось.

> У нас есть WInChar

Но в нем кода в 4 раза больше чем в дельфийском варианте )

Вот код из D2010.SysUtils:



Вы считаете, это корректное решение? Например, для случая W in [ 'А'..'Я' ] ?
Эту функцию правильнее было бы назвать CharInAnsiSet, и документировать детально, что проверять не-анси символы она не может.

А кода в 4 раза больше в самой функции или в каждой точке вызова? (Вообще говоря, в 4 раза больше даже во многих точках вызова не может привести к фатальному росту кода во всем приложении, если только речь не о добавлении N Кбайт из-за динамических массивов).

Копипастить в любом случае не имеет смысла: ее придется обложить IFDEF'ами, т.к. прежние версии Delphi не поймут. А смысл тогда какой? Такую функцию где угодно можно разместить, в любом модуле у себя. Если бы она еще автоматически действовала на запись W in [x..y,z] , так ведь код все равно надо свой переписывать, чтобы обращаться к charinset'у.

> Вы считаете, это корректное решение? Например, для случая
> W in [ 'А'..'Я' ] ?

Может и не совсем корректное, но зато быстрое и инлайном ) А поменять на это можно в самом KOL, окружив ifdef-ом, тем более что вроде как только одно место всплыло (ворнинг дельфя выдает).

Почему инлайном? (Код я посмотреть не могу, IDE не запускается). А если инлайном, то будет ли оно инлайном, если код скопипастить?

Вообще, есть вариант достаточно эффективный:
- для проверок наличия диапазона заменять на (w >= 'А') and (w <= 'Я')
- для проверок некоторых символов использовать pos( w, 'АБВ' ) > 0

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



либо ориентироваться строго на _D2010. Или все-таки сделать вариант CharInSet для других версий, заменив тип TSysCharSet на свой или объявить его для старших версий
и рекомендовать пользоваться функцией вместо действительно инлайн-кода, который генерит in.

А то, что одно место, я его сам поправлю. Только до дома дойду вечером, там D2010 "стоит" без IDE, с -DDEBUG откомпилирую, и поправлю.

Я вообще считаю, что то, как Embarcadero сделало с переопределением String на UnicodeString - неправильно в корне. Это можно было сделать опцией по умолчанию, но обязательно нужна была директива, возвращающая все на свои места. Это точно такое же неправильное решение, как решение об использовании unicode-16: решение как в Linux использовать UTF-8 было бы намного правильнее с точки зрения совместимости. Таоке ощущение, что это было специально для обеспечения максимальной несовместимости.

Версия 3.00.X на сайте. Поправил с -DDEBUG и заодно где увидел все in [ ] для Char. Не стал трогать только явный AnsiChar in [ ]. Восстановил работу MCK в Delphi2/3.

> А если инлайном, то будет ли оно инлайном, если код скопипастить?

Вообще, инлайны с 2007 версии точно поддерживаются :) И они реальные инлайны. Мне очень понравились инлайновые методы в хелперах для записей. Например, делаем хелпер для TRect, добавляем ему инлайн метод Width, вставляем строчку кода и вуаля, в коде везде пишем rect.width, а в конечном бинарном коде получаем работу с Left и Right без вызовов функций. Одно плохо - IDE не любит такие штуки. В Дельфи ХЕ этот момент вроде доработали, но не тестировал еще, до конца ли (я им плавающую ошибку из-за хелперов год ловил, когда поймал - в багтрекере ответили что в ХЕ поправлено). На работе сейчас используем 2010, и там очень успешно применяем свойства объектов, get методом которых являются инлайн функции. Т.е. обращаемся к свойству, а в конечном коде инлайн разворачивается и работает например с полями без лишних вызовов.


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

Я не настаиваю, в общем то, на решении методом копипаста, просто предложил ) Если можно обойтись без лишних добавок, то я только за )


> с переопределением String на UnicodeString - неправильно
> в корне

На сколько я понял из исходников - rtl можно откомпилить без нативной поддержки юникода. Там есть не мало {$IFDEF UNICODE}.


> это было специально для обеспечения максимальной несовместимости

На самом деле аккуратно написанный код не нуждается в правке при переходе на юникод, дельфийцы над этим поработали хорошо. Единственный момент - это когда выделяется память под строки, тут да, мало кто писал конструкции вида GetMem(ptr, Length(str) * Sizeof(Char)), умножать на размер символа не привыкли. Но рабочие бизнес-приложения без этого легко обходятся. У нас, например, с парой пустяковых правок нормально откомпилился и заработал большой проект. Бал на 2007, переводили на 2009.

> аккуратно написанный код

Дело не только в аккуратности. Паскаль имеет много гитик, связанных с его низкоуровневостью. Я видел, народ был в панике из-за использования строк в качестве динамических массивов при обмене данными в ком-объектах. Потом, кому на протяжении 20 лет могло в голову прийти писать умножение на размер оф чар, если он всегда = 1 ? Супермазохизмом никто не страдает, да еще код загромождать. Кто теперь будет просматривать миллионы строк старого кода только потому, что новые хозяева решили изменить незыблемую казалось бы аксиому. Да если и будет, сколько времени пройдет, пока будут устранены все такие неаккуратности. rtl перекомпилировать - это они сами пусть сначала попробуют. Я лично все равно не собираюсь на d20xx переходить, моя организация тоже - ей надо обеспечивать поддержку для платформы nt4/win2k, на висту/семерку/восьмерку никто здесь переходить не планирует до 2020 года точно. А если будут переходить, то уже не на delphi точно. C#, J#. Опцию надо было оставлять для совместимости, чтобы клиентов не терять хотя бы.

3.00.Y - теперь и в Delphi3 можно использовать ключ -DUNICODE_CTRLS.

Finally I created bat files to compile from different compilers using most often problem keys. May be this will help in future modifications.

Новый вариант TStrList.IndexOfName падает =\
пока не разобрался почему и когда именно..

Постейший код падает

Забыл сказать, что старый вариант(IndexOfName_old) - работает