Предложение по доработке MCK для совместимости с автоформатерами

← →
VPBar (2007-05-13 10:48) [0]

Приветствую. Довольно давно пользуюсь KOL (еще с версии 1,80). И обнаружил что при использовании автоформатера в KOL-проектах, начинаются странные глюки. Как оказалось причина в том что форматер убирает пробел в этой строчке "{ KOL MCK } // Do not remove this line!". MCK не находит в проекте свою сигнатуру и заново добавляет ее и инклюды в обьявлении формы. Естественно это уже не компилится. Решение такое:
Добавляет константу и функцию в mirror.pas
... const VSignature = "{KOLMCK}//DONOTREMOVETHISLINE!"; .... // asPos=false - точное совпадение S с сигнатурой. // Иначе проверяет вхождение сигнатуры в S function isValidSignature(S:String;asPos:Boolean=false):Boolean; begin S:=KOL.RemoveSpaces(S); if asPos then result:=Pos(VSignature,KOL.UpperCase(S))>0 else result:=StrComp_NoCase(PChar(VSignature), PChar(S))=0; end; .....
затем все строки где идет сравнение сигнатуры (if Source[ I ] = Signature then) меняем на
if isValidSignature(Source[ I ]) then.
И там где идет поиск сигнатуры (if pos( Signature, Source[ I ] ) > 0 then) так же меняем на
if isValidSignature(Source[ I ]) then.
Эти изменения делают MCK менее привередливой.
Пару лет назад, я уже предлагал на форуме(по моему даже именно на этом) Кладову включить эти изменения в MCK. Но почему-то это не было сделано. Видимо решение не понравилось, или такая проблема возникла только у меня, а остальные форматируют все ручками. Сейчас я опять предлагаю обсудить целесообразность этих изменений. И если они нужны предложить автору KOL внести их в новую версию. Кроме того я изменил MCK, так чтобы он ложил все свои инки в папку kol_inс папки проекта. (Ну не нравится мне заваленная инками папка проекта :) ). Естественно после этих изменений MCK имеет обратную совметимость со старыми проектами (сделанными в MCK без этих изменений). Вот модифицированная мной версия http://slil.ru/24359538 * VERSION 2.58

← →
Дмитрий К © (2007-05-13 17:15) [1]

> ...причина в том что форматер убирает пробел в этой строчке ...

Есть, как минимум, 2 варианта решения этой "проблемы":
1. Запретить "форматеру" убирать пробел.
2. Написать "форматер", кот. будет правильно обрабатывать сигнатуру MCK.

А менять код библиотеки ради каких-то "форматеров", на мой взгляд, - зло.

Все вышенаписанное - IMHO.

← →
Vladimir Kladov (2007-05-13 18:32) [2]

Я не использую автоформатеры, которые еще и коверкали бы текст. Но если он только пробелы по-своему расставляет, то поборемся еще раз. У нас есть функция RemoveSpaces, вот ее и применим в MCK при сравнении сигнатур, чтобы было все равно, сколько там пробелов ваш кривой форматер сделал.

← →
VPBar (2007-05-13 19:09) [3]

>> Дмитрий К
Вы готовы написать форматер специально для MCK, но не готовы изменить несколько строчек в MCK?
Ну не всречал я нормальных автоформатеров, в которых можно заперить форматировать строку с определенным текстом.
>> Vladimir Kladov
Я знаю, что Вы не используете автоформатеры, Вы это уже отвечали. К сожалению все форматеры "коверкают" текст под определенный формат :).
В принципе для меня не большая проблема, вносить эти изменени в каждую версию. Просто решил вынести предложение на обсуждение.
Кроме того, решение это проблемы восстановить точность - в строчке
"{ KOL MCK } // Do not remove this line!" - говорится только о том, что нельзя удалять строчку. Хотя точнее было бы "{ KOL MCK } // Do not change this line!". Хотя это конечно мелочь.
Заранее спасибо, если Вы примените RemoveSpaces в новых версиях.

← →
Vladimir Kladov (2007-05-13 21:25) [4]

Да, и говорится это человеку. Поэтому писать DONOTREMOVE... без пробелов внутри и большими буквами - вообще неправильно. Сигнатуру я оставлю ту же, поправлю только проверку в тех местах, где она делается.

← →
vpbar (2007-05-14 12:21) [5]

Спасибо.

Предложение по доработке MCK для совместимости с автоформатерами Найти похожие ветки