Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

Будет ли работать сайт KolMck.net?


Sheleh   (14.07.16 11:46

Было очень удобно порой на него заглядывать. Если бы знал, что он исчезнет, наверное бы закачал его целиком заранее и захостил бы в виде зеркала. Если у кого осталось содержимое ресурса, буду рад, если поделитесь. Могу выложить на своем компе с именем вроде kolmck.ddns.net.


RusSun ©   (14.07.16 18:46[1]

https://web.archive.org/web/*/http://kolmck.net/


Sheleh   (14.07.16 20:45[2]

Фигасе! Я даже не знал, что бывает такой сервис.


RusSun ©   (18.07.16 19:56[3]

The mail system

<vk@kolmck.net>: Host or domain name not found. Name service error for
   name=kolmck.net type=MX:

Host not found, try again .(


RusSun ©   (22.07.16 04:53[4]

https://yadi.sk/d/S4_uXcYutWwK9

a 404 Not Found Apache/2 Server at kolnmck.kolmck.net Port 80
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
в истории KOL&MCK
news :
http://kolmck.net/news2/e_new310.htm
http://kolmck.net/news2/e_new300.htm
Downloads
o KOL&MCK:
http://kolnmck.kolmck.net/files/components/mckext/mckappexpert_kol2xx.7z

http://kolmck.net/e_adds.htm:
http://kolmck.net/e_links#links -куда-то ведёт)

http://kolnmck.kolmck.net//files/components/formext/mhxp.7z -> то работает, то нет я не понял.)
KOLmdvDialogEx http://kolnmck.kolmck.net/files/components/dialogs/kolmdvcontrols.7z
KOLmdvXLGrid http://kolnmck.kolmck.net/files/components/controls/kolmdvcontrols.7z
KOLmdvPanel http://kolnmck.kolmck.net/files/components/controls/kolmdvcontrols.7z
KOLmdvGliphLabel http://kolnmck.kolmck.net/files/components/controls/kolmdvcontrols.7z
KOLPng-> and KOLZLib v2.151 or higher-> http://kolmck.net/e_adds.htm#KOLZLib -> не переходит
После SmoothDIB идет BIS -> не работает хотя в другом месте есть рабочий
http://www.mdvkol.narod.ru/KOLmdvGenRTF.zip есть сохраненый файл KOLmdvGenRTF.zip
http://kolmck.net/e_apps.htm:
http://vp.irk.ru/ivcalcsetup.exe не работает но мне удалось скачать файл ivcalcsetup.exe
http://titan.spaceports.com/~yoursoft/my/allrep.zip (есть сохраненая страница с рабочим мыло всё ссылки битые)
http://www.psgsoft.com/cdeject.zip не нашел.
http://set.nm.ru/o!drive.zip не робит у меня есть сохраненый файл o!drive.zip
http://kolmck.net/apps/AdvancedFileCopy.zip есть сохраненый файл AdvancedFileCopy.zip
http://kolmck.net/apps/Starter.zip есть сохраненый файл Starter.zip
http://home.netvigator.com/~mso6f/100ziper.exe есть сохраненый файл 100ziper.exe
Optool есть сохраненный файл Optool12beta_Setup.exe

http://kolmck.net/e_tools.htm:
строка If you are going to use only Updater to apply >updates<- http://kolmck.net/e_updates.htm не работает
http://speller.narod.ru/plugins/peviewer/peviewer_1.11.rar есть сохраненый файл peviewer_1.11.rar

----------------------------------------------------------------------------


Dimaxx ©   (25.09.16 13:56[5]

Остался ли у кого-то архив с компонентами Кладова для VCL? Архив назывался, если склероз не изменяет, KladovVCL.zip.


Дмитрий К ©   (25.09.16 18:22[6]

http://www.filedropper.com/vclcomponentskladov


Dimaxx ©   (25.09.16 22:48[7]

Премного благодарен!


Mike   (05.11.16 05:56[8]

Будет жить?
Или KOL умер??


Dimaxx ©   (05.11.16 12:21[9]

Нынешний, вероятно, умер.

В КОЛе утечек памяти много - проверил на FPC. Код получается "грязный". КОЛ надо переписывать с объектов на классы. Немного увеличится размер, но будет проще. Плюс либо избавляться от асма совсем, либо дописывать варианты для 64 бит на асме.


Helpercode   (05.11.16 22:11[10]

>Плюс либо избавляться от асма совсем.

Солидарен. Много много лет назад я об этом говорил. Очень сложно поддерживать и синхронизировать библиотеку написанную на двух языках.


Awkward ©   (06.11.16 08:50[11]

KOL задумывался как кодоэкономичная библиотека, классы добавят навороты  и убавят экономичность. Но лично я, например, тоже не против избавления от асма.


Dimaxx ©   (06.11.16 14:52[12]

На данный момент размер исполняемого файла всем пофигу. Я согласен с тем, что сложное приложение, имеющее размер COMMAND.COM это круто (и мне самому это нравится - что уж тут скрывать), но в данное время при наличии терабайтов на диске и 100мбит/1Гбит каналов связи размер мало имеет значения.

Классы добавят автоматическое удаление потомков и все связанное с этим. Упростится переделка сторонних компонент. Пропадут утечки памяти, связанные с постоянной работой с указателями на объекты. Появится полноценная возможность трассировки с просмотром любых значений свойств этих объектов (читай классов) - в данный момент отладчики D5/D7 (более старшие не пробовал) не могут полноценно работать с объектами (это мелочи). Немного улучшится кроссплатформенность - КОЛ несет в себе все, не требуя практически никаких доп. модулей, кроме стандартных. Я замучался адаптировать КОЛ под FPC - а когда он наконец-то заработал и я увидел, что творится в памяти - понял, что нуегонафик эти объекты. При всех этих достоинствах я соглашусь на некое увеличение кода. В FPC 3.0 в 32-битном режиме exe с пустой формой занимал примерно 31кб, в 64-битном - 47кб. Что все равно ГОРАЗДО лучше громадных VCL-приложений, которые растут как на дрожжах. Так что 16кб и 32кб в D5 - невелика разница.


L`Autour   (07.11.16 06:55[13]

В Delfi тоже утечки?


Dimaxx ©   (07.11.16 12:38[14]

В Дельфи нет средства для контроля за утечками памяти.


DKOL   (08.11.16 09:29[15]


> В КОЛе утечек памяти много - проверил на FPC


А где конкретно?


> В Дельфи нет средства для контроля за утечками памяти.


Есть отдельный memproof
Есть встроенный\и отдельно устанавливаемый FastMM
Есть madCollection...

Периодически смотрю - никаких утечек.. Поэтому неплохо бы конкретики


Dimaxx ©   (08.11.16 21:25[16]

Сначала везде где есть создание объектов и выделение памяти (а также освобождение) поставил вывод в лог всего что, в каких кол-вах запрашивается и удаляется. Выяснилось, что объекты создаются дважды(!!). Мб это особенность FPC, но форма с меткой и кнопкой создает два объекта формы, 2 кнопки и 2 метки. Везде где есть Getmem/Freemem все создается и освобождается правильно. Но объекты создаются дважды, а удаляются 1 раз. Встроенная в FPC проверка на утечки этого же приложения в лог выдает - запрошено 11 областей памяти, освобождено 8 или 9 (не помню точно). Допускаю, что средство неверно работает с объектами, равно как и FPC может отличаться особенностями работы с объектами. Но нет никакой гарантии, что вышеприведенные средства для Дельфи гарантированно верно работают с объектами. В итоге "все хорошо, прекрасная маркиза" также могут быть и неверными данными.


L`Autour   (09.11.16 06:38[17]

Вполне возможно, что при развитии FPC что-то переделали, а об объектах банально забы(и)ли.


Dimaxx ©   (09.11.16 12:45[18]

Объекты оставлены в режиме совместимости со старых версий. Это, емнип, частный случай класса в старых досовских турбо-паскалях и ныне считается как устаревший. В итоге отладчик ни в одной версии (новее бесплатного Turbo Explorer'а не проверял) не работает с ними корректно. Опять-таки, емнип, они есть, но их не рекомендуют использовать.

Взято с этого же форума:
object, в отличие от class, не требует обязательного выделения кучевой памяти для размещения экземпляра, поэтому экз-р object может быть автоматически создан компилятором в секции данных или в стеке, в зависимости от того где он объявлен.

>> а об объектах банально забы(и)ли
Это вряд ли. Тогда их просто выбросили бы, раз они устаревшие.


L`Autour   (09.11.16 13:28[19]

По автоматическому созданию объекта - это только для статического объекта. Утечек в этом случае по идее должно быть не больше чем от локальных\глобальных переменных.


Dimaxx ©   (09.11.16 13:53[20]

Дело не в этом, это все лирика. Но ясно одно - нужно отказываться от асма полностью, и, желательно, от объектов.


DKOL   (09.11.16 14:38[21]


> Выяснилось, что объекты создаются дважды(!!)

Интересная штука.. но у меня подозрение, что это происходит только в fpc.
А как воспроизвести? Только в формами\контролами такая штука или достаточно создать простой PStrList их будет два?


>  поэтому экз-р object может быть автоматически создан компилятором
> в секции данных или в стеке, в зависимости от того где он
> объявлен.

На самом деле классная штука, объект может лежать просто на стеке... но увы..


> В итоге отладчик ни в одной версии (новее бесплатного Turbo
> Explorer'а не проверял) не работает с ними корректно.

А как проявляется? Просто о некоторых особенностях в курсе, например нельзя юзать default параметры или криво помощник кода отрабатывает, но это не про отладчик..


> Но ясно одно - нужно отказываться от асма полностью, и,
> желательно, от объектов.

Тут вот смотря как посмотреть...
Если есть желание юзать новые версии (выше упомянутой турбы, хотя.. даже на ней с классами будет чуть да удобнее), то классы удобнее.. но кода будет больше.. Но насколько помню из-за уродской архитектуры новых версий принудительно цепляется sysutils(это в тех, что смарел.. а в более новых мб и еще чего..)
Если есть желание юзать х64 - то тут только PAS_VERSION.. и опционально отказ от объектов..

А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..

И немного лирики насчет отказа от объектов в пользу классов:
1) Просто поменять object -> class - это вряд ли много работы будет.. Хотя уже от привычных List: PStrList/NewStrList надо будет отказаться в пользу List: TStrList/TStrList.Create
2) Или же полностью менять архитектуру на использование виртуальных методов


HelperCode   (09.11.16 15:51[22]

> А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..

Смысл в следующем. Если кто-нибудь решит исправить или дополнить версию на Паскале, то кто будет вносить изменения (дополнения) на Ассемблере.


Awkward ©   (09.11.16 16:45[23]

Использовал объекты у себя через FPC без KOL,  создаются один раз, никаких утечек. Так что не думаю, что имеет смысл отказываться от объектов.


Dimaxx ©   (09.11.16 17:19[24]


> А как проявляется?

Проявляется, когда в пошаговом режиме наводишь, допустим, на используемый Form.Width и в подсказке вместо значения появляется либо Illegal value, либо AV (хотя значение там есть и верное). С классами такого нет. Д5-Д7 точно, про турбо не помню - мало юзал.


> или достаточно создать простой PStrList их будет два?

Не проверял. Проверял тока с контролами. Дальше проверять не было желания.


> но кода будет больше

По сравнению с VCL - прибавка мизерная. От VCL приложение пухнет активнее. Если правильно помню, то просто +1 юнит в приложении это уже +8...10кб лишнего кода, помимо кода самого юнита.


> Если есть желание юзать х64 - то тут только PAS_VERSION

В коде много кода на асме без версий на паскале - для 64 бит такой фокус не прокатит.


> Просто поменять object -> class - это вряд ли много работы будет

Ничего не получится. Придется переписывать. В одном тока TControl черт ногу сломит. Если TList еще просто переписать, то TControl просто так не сдастся.


> Хотя уже от привычных List: PStrList/NewStrList

Зачем? Никто не мешает писать:

function NewStrList: TStrList;
begin
 Result:=TStrList.Create; // вместо New
 Result.<параметр>:=<значение>;
end;



> Использовал объекты у себя через FPC без KOL

Ключевое слово "без".


Awkward ©   (10.11.16 08:47[25]

> Ключевое слово "без".
Я имею в виду, что проблема, если и есть, то в KOL, а не в object как таковых


DKOL   (10.11.16 08:55[26]


> Form.Width и в подсказке вместо значения появляется либо
> Illegal value, либо AV (хотя значение там есть и верное).
>  С классами такого нет. Д5-Д7 точно, про турбо не помню
> - мало юзал.


Конкретно данный пример отрабатывает в турбе нормально. А вот тот же проперти TStrList.Count показывает бред.. надо смотреть саму переменную fCount. Вообще не сильно удивлюсь если в новых версиях object выпилят полностью..


> По сравнению с VCL - прибавка мизерная. От VCL приложение
> пухнет активнее. Если правильно помню, то просто +1 юнит
> в приложении это уже +8...10кб лишнего кода, помимо кода
> самого юнита.

В том то и дело, что там цепляется sysutils, который тащит еще модули за собой.


> Зачем? Никто не мешает писать:

Так у меня такой же вопрос возникает, а зачем так писать?)
Когда уже перешли на классы и привычное написание будет как раз через "TClass.Create;"


> В коде много кода на асме без версий на паскале - для 64
> бит такой фокус не прокатит.


Когда собирал последний SVN, то насколько помню там компилировалось все в х64.. Да и не замечал, что есть кода чисто на асме без пас версии.

Если затевать какие то глобальные переходы, то нужно это делать поэтапно. Сначала одно, потом другое и т.д..
Вопрос кто будет это делать? Кому это реально надо? И что Владимир думает поэтому поводу..?


Dimaxx ©   (10.11.16 11:34[27]


> там цепляется sysutils, который тащит еще модули за собой.

Он дает прибавку 40-50кб и ничего лишнего не тащит за собой. Основная масса кода - Classes, Forms, контролы. Вот там тащится все беспорядочно. Один Classes, емнип, таращит код на 200+ кб.


> привычное написание

Можно оставить обратную совместимость через условную компиляцию. Старый синтаксис уменьшит переделку уже написанного.


> делать поэтапно

Поэтапно не получится - там все завязано на всем.


> Вопрос кто будет это делать?

Вопрос открытый. Могу я, но мне, к примеру, нафик не нужен линух. Значит я выкину все к нему относящееся. Мне не нужна совместимость с тонной разных версий (меня интересует D5-D7 и FPC) - соответственно тоже выкину. Всяческие нагромождения под CommandActions и USE_FLAG также полетят в помойку. И т.д. и т.п.


> Кому это реально надо?

Вопрос также открытый. А надо ли это вообще? Меня не парит в D7 писать на VCL - размер exe там приемлемый. А вот если понадобится написать что-то коммерческое - у FPC exe жирнючий как свинья, но за полным отсутствием аналогов сойдет. Explorer - обрезок (сторонние компоненты поставить можно, но только в подписанный сигнатурой дефолтный пакет). Дельфи не подходит из-за отсутствия лицензии.


> И что Владимир думает поэтому поводу

Владимира, видимо, давно не волнует судьба КОЛ. Емнип, он его отдал на откуп общественности. Весной не отвечал даже на письма. Тут не появляется давно.


DTy   (22.11.16 12:03[28]

мне нужен КОЛ, но только для моего древнего навигатора. То есть размер поменьше и под 6-ой арм (кросскомпилятор Лазаруса умеет 4-ый). Для остального уже 5 лет есть C#


L`Autour   (23.11.16 13:32[29]

C# - это идеологически антипод KOL.


Dimaxx ©   (27.11.16 17:47[30]

function TBitmap.ReleaseHandle: HBitmap;
var OldBits: Pointer;
begin
 HandleType := bmDIB;
 Result := GetHandle;
 if Result = 0 then Exit; // only when bitmap is empty
 if fDIBAutoFree then
 begin
   OldBits := fDIBBits;
   fDIBBits := Pointer( GlobalAlloc( GMEM_FIXED {or GMEM_ZEROINIT}, fDIBSize ) );
   Move( OldBits^, fDIBBits^, fDIBSize );
   GlobalFree(THandle(OldBits));  <-- ДОБАВИТЬ
   fDIBAutoFree := FALSE;
 end;
 fHandle := 0;
end;


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


Dimaxx ©   (27.11.16 18:10[31]

procedure TBitmap.ClearData;
begin
 fDetachCanvas( @Self );
 if fHandle <> 0 then
 begin
   DeleteObject( fHandle );
   fHandle := 0;
   fDIBBits := nil; ЗАЧЕМ???
   // Память выделена, а мы ее просто забываем!!! Убрать!
   // Если она еще не освобождена, то в следующих строках будет освобождена.
 end;
 if fDIBBits <> nil then
 begin
   if not fDIBAutoFree then
     GlobalFree( THandle( fDIBBits ) );
   fDIBBits := nil;
 end;
 if fDIBHeader <> nil then
 begin
   FreeMem( fDIBHeader );
   fDIBHeader := nil;
 end;
 fScanLineSize := 0;
 fGetDIBPixels := nil;
 fSetDIBPixels := nil;
 ClearTransImage;
end;


Гость   (27.11.16 23:59[32]

В который раз...
Есть архив сайта kolmck.net (не помню, раньше его выкладывал или нет) от 12.01.2014 года.
Посмотрю еще были еще архивы сайтов Тедди и как мне кажется более поздние архивы kolmck.net.


L`Autour   (28.11.16 11:13[33]

Dimaxx
По TBitmap.ReleaseHandle:

Там развязывание объектов (без удаления отвязываемого). DDB, при обнулении (отвязки) fHandle превращается в DIB с независимым fDIBBits (копией ранее привязанного объекта). А старый участок памяти остается с отвязанным объектом и удалеятся при необходимости вместе с ним.

По TBitmap.ClearData:

под fDIBBits память выделяется при NewDIBBitmap, при этом fHandle равно 0.
Если потом присвоить fHandle, то судя по  TBitmap.SetHandle вроде последующая очистка памяти будет уже через fDIBHeader.


Dimaxx ©   (29.11.16 21:08[34]

DeleteObject удаляет все связанное с хэндлом. Так что ClearData оправдана - там все верно.


An a Student   (29.11.16 23:45[35]

Читал что не удаляет, а помечает как освобождённое. То есть после DeleteObject оно ещё лежит в памяти неопределённое время.


An a Student   (29.11.16 23:47[36]

Забыл, для тех кто не заметил соседнюю тему (или на случай если она потеряется):

"Поднято зеркало прежнего сайта по адресу http://kolmck.ru" © Vladimir Kladov


L`Autour   (30.11.16 06:30[37]

Dimaxx
из KOLBook по TBitmap


числе, для изображений, зависящих от устройства);
Handle - дескриптор системного графического объекта типа hBitmap. Независимые от устройства изображения не нуждаются в наличии такого дескриптора, и вообще всю работу потенциально могут выполнять без выделения такого дескриптора. Однако, если идет работа с изображением через канву, дескриптор для изображения создается автоматически. Допускается присваивать этому свойству в качестве значения дескриптор битового изображения (типа hBitmap), полученный любым способом, в том числе из API-функций - при этом прежнее изображение теряется и замещается присвоенным, а объект становится "владельцем" присвоенного дескриптора (т.е. дескриптор будет автоматически разрушаться вместе с объектом в его деструкторе);



> ReleaseHandle - отделяет дескриптор от изображения, освобождая
> его (независимое от устройства изображение продолжает при
> этом существовать в памяти, и при необходимости выполнения
> каких-либо операций, требующих наличия дескриптора, тот
> будет выделен снова). Отделенный в результате такой операции
> дескриптор освобождается в том смысле, что с этого момента
> он не известен (и не интересен) объекту TBitmap. И тогда
> уже вызывающий код отвечает за его дальнейшую судьбу. Например,
>  он может быть удален API-функцией DeleteObject, или использован
> каким-либо еще способом. Важно лишь обеспечить отсутствие
> утечек таких ресурсов: все выделенные ресурсы GDI, к которым
> относится и hBitmap, должны быть обязательно удалены, когда
> надобность в них отпадает;


поэтому и там все верно.


L`Autour   (30.11.16 06:37[38]

сорри за форматирование.


RusSun ©   (30.11.16 19:02[39]


> В который раз...
> Есть архив сайта kolmck.net (не помню, раньше его выкладывал
> или нет) от 12.01.2014 года.
> Посмотрю еще были еще архивы сайтов Тедди и как мне кажется
> более поздние архивы kolmck.net.

Доброе время суток.
Напишите мне или выложите ссылку в этой теме.
Особенно интересны архивы сайтов Тедди так сейчас их не найти. Спасибо.


An a Student   (01.12.16 01:39[40]

Я так понял гость предлагал поискать Тедди на https://web.archive.org/web/...
Не помню где была офф.страница, напомните?

Попытался найти на https://web.archive.org архивную копию http://kolmck.ru - не было - "архивов 0". Через сутки написало "архивов 1", но всё равно не открывает... Кто умеет, задвиньте ему как там нужно...


Awkward ©   (01.12.16 23:04[41]

А что Taddy? http://members.chello.nl/t.koning8/ у него живо с сырцами, вроде. что ещё у него могло быть?


RusSun ©   (02.12.16 18:39[42]


> вроде. что ещё у него могло быть?

Что могло быть знает Гость.
...
были же и более ранние, которые после не выкладывались.
через https://web.archive.org не найти потому, что для web.archive.org
это единичные сохранения. В отличие от http://kolmck.ru

> http://kolmck.net/
> Saved 114 times between ноября 16, 2006 and мая 11, 2016.
> PLEASE DONATE TODAY. Your generosity preserves knowledge for future
> generations. Thank you.


An a Student   (06.12.16 08:55[43]

Что-то пытаюсь отправить сообщение - и не выходит. Молча открывается корень ветки и всё... Не понятно из-за чего... Так, а если ток последние два предложения...

На данный момент входить надо по такой ссылке: http://web.archive.org/web/20161206042443/http://kolmck.ru/index.html
Я основные страницы уже сохранил, остальное не знаю как автоматом делать, руками будет долго и с ошибками...


Dimaxx ©   (11.01.17 23:53[44]

У кого есть доступ для правок к https://sourceforge.net/p/kolmck/code/HEAD/tree/?

В TBitmap.RLESaveToFile в функции WriteBitmap надо исправить утечку:

Buffer := AllocMem( Width );
for y := Height-1 downto 0 do
begin
 Line := ScanLine[y];
 x := 0;
 while x < Width do
 begin
   Buffer[x] := Line^ shr 4;
   inc( x );
   if  x >= Width then break;
   Buffer[x] := Line^ and 15;
   inc( x );
   inc( Line );
 end;
 MS.Write( Buffer^, Width );
end;
MS.WriteVal( 0, 2 );
FreeMem( Buffer ); <--- без этой строки - утечка


Vladimir Kladov ©   (13.01.17 20:55[45]

kolmck.ru - это свежевыложенное зеркало, для доступа к нему не нужна машина времени. Старая версия - это kolmck.net.


Dimaxx ©   (14.01.17 12:54[46]

Выложенный код на sourceforge не компилируется под FPC 3.0. Для работоспособности в KOLDEF.inc надо сделать изменения:

{$IFDEF FPC}
{$MODE DELPHI}  <------------------------ добавить
{$ASMMODE INTEL}  <--------------------- добавить

{$DEFINE PAS_ONLY}
{$DEFINE USE_OLD_FLAGS} //size of set type in fpc is 4 bytes
{------------------------------------
by Thaddy de Koning:

FPC version 2.1.1 is very compatible with Delphi and kol now.
You can simply use the $(DELPHI)\source\rtl\win\*.pas files from Delphi 4/5 instead of the prepared files that were needed for
FPC1.X

That is all to have full compatibility.
------------------------------------}
{$DEFINE PAS_VERSION}
//{$IFDEF VER2}  <------------------------ отключить
{$DEFINE _D3orHigher}
{$DEFINE _D4orHigher}
{$DEFINE _D5orHigher}
{$DEFINE _D6orHigher}
{$DEFINE _D7}
{$DEFINE _D7orHigher}
//{$ENDIF}  <----------------------------- отключить
{$ENDIF FPC}


После правок код рабочий в 32/64.


Dimaxx ©   (14.01.17 13:31[47]

Либо сделать как предложил Thaddy здесь http://delphimaster.ru/cgi-bin/forum.pl?id=1464765728&n=10


DKOL   (14.01.17 13:44[48]

Dimaxx, А как лучше то? Не использую фпц, нет возможности проверить


Dimaxx ©   (14.01.17 16:51[49]

В варианте Thaddy можно использовать и старые версии FPC. Ток в вышенаписанном мною забыл добавить после {$DEFINE _D7orHigher} строки

{$DEFINE _D2005orHigher}
{$DEFINE _D2006orHigher}
{$DEFINE _D2007orHigher}


Dimaxx ©   (15.01.17 01:38[50]

Кстати, в свое время Владимир говорил про то, что приходилось выбрасывать лишнее в KOLadd из-за того, что KOL.pas превышал 65к строк. Так вот KOL.pas надо основательно почистить - там море пустых строк, закомменченного кода + последовательное объявление переменных в объектах одинакового типа можно свести в одну строку. Ну и желательно отформатировать код для аккуратного вида.


DKOL   (18.01.17 11:02[51]

Dimaxx, добавил вариант от Thaddy(без проверок), чтоб можно было и старые версии использовать.

Выкинуть мусор и отформатировать код было бы не плохо.. Но, например, для меня:


> последовательное объявление переменных в объектах одинакового типа можно свести в одну строку.


и


> отформатировать код для аккуратного вида


Взаимоисключающие вещи :)


Dimaxx ©   (18.01.17 21:03[52]


> Dimaxx, добавил вариант от Thaddy(без проверок), чтоб можно
> было и старые версии использовать.

{$MODE DELPHI} и {$ASMMODE INTEL} надо добавлять обязательно - не компилируется.


> Взаимоисключающие вещи :)

Ну так приходится чем-то жертвовать. Кстати, там в некоторых местах в record'ах так уже сделано.


DKOL   (30.01.17 12:13[53]


> надо добавлять обязательно


Добавил, будет время - проверьте


> Ну так приходится чем-то жертвовать. Кстати, там в некоторых
> местах в record'ах так уже сделано.


Сейчас общий вид форматирования представляет кашу.. Да и редактор кода тупит для KOL.pas


Dimaxx ©   (27.02.17 22:01[54]

Неверно работает свойство контрола AnchorBottom, если он лежит, к примеру, на GroupBox - по идее должен привязываться к границе родителя (GroupBox), а он привязывается к форме. В итоге нижняя граница контрола находится на уровне нижней границы GroupBox.

К сожалению в анчорах не силен, поэтому как поправить не знаю.


Dimaxx ©   (27.02.17 22:09[55]

A AnchorRight работает верно, но увеличивает ширину на лишние 2 пикселя.


Dimaxx ©   (01.03.17 15:44[56]

Вдогонку: непонятно как работает создание контрола - настраиваю шрифт у KOL-формы и шрифт по умолчанию у KOLProject. Кидаю на форму GroupBox - он наследует шрифт формы. Кидаю кнопку или метку - шрифт другой. Хотя в дизайнере шрифт верный и все верно отображает.


DKOL   (14.03.17 16:49[57]


> Неверно работает свойство контрола AnchorBottom, если он
> лежит, к примеру, на GroupBox - по идее должен привязываться
> к границе родителя (GroupBox), а он привязывается к форме.
>  В итоге нижняя граница контрола находится на уровне нижней
> границы GroupBox.


А есть ли такой же баг если использовать Panel вместо GroupBox.

У GroupBox есть еще глюк со шрифтом - если в GroupBox кинуть другой GroupBox то шрифт искажается


sheleh   (17.03.17 20:55[58]

То то я думаю, что за фигня. Пишу альтернативу explorer.exe
Екзешник маленький 72Кб, а памяти отжирает 40 мб. Надо было изучать С

https://yadi.sk/d/N1zyD3fpfSQAG


Dimaxx ©   (18.03.17 00:47[59]

KOL жрет столько же, сколько и VCL. Доп. отжирание зависит от запросов в коде. И не факт, что тот же код на Си будет жрать меньше.


Dimaxx ©   (19.03.17 00:39[60]

>> А есть ли такой же баг если использовать Panel вместо GroupBox.
Если не уменьшать до 0 размер панели, то нет. При изменении размера панели до 0 после обратного увеличения нижняя граница контрола на панели уезжает до нижней границе панели. А после нескольких произвольных изменений до 0 и обратно нижняя граница панели вообще съезжает до нижней границе формы.

PS: Изменение размеров происходит изменением размеров формы - все Anchor'ы панели True, Anchor'ы контрола внутри также все True.


DKOL   (23.03.17 12:02[61]

Мда.. GroupBox совсем глючный..

Проверьте еще есть ли баг со шрифтом - берем GroupBox, на него кидаем другой GroupBox и смотрим их Caption'ы, не исказился ли шрифт?


Dimaxx ©   (23.03.17 21:02[62]

Со шрифтом все интересно. Он наследуется от формы, но размер почему-то свой, отличный от размера шрифта формы. Но! Достаточно поменять стиль шрифта программно у всей иерархии GroupBox - Font.FontStyle:=[] (или, например, размер шрифта) и тут же весь шрифт (включая все контролы, которые лежат внутри GroupBox) становится в точности как у формы. Даже у вложенных GroupBox'ов. Только менять параметры шрифта надо у всех GroupBox'ов - у тех, у кого не поменяем параметры шрифта останутся прежними, включая все контролы внутри GroupBox'ов. Точно также и у формы - пока не поменяем у нее какое-нибудь свойство шрифта, не меняется, хотя в редакторе все шрифты выставляются в точности с указанными. Плюс у GroupBox'а почему-то в редакторе цвет шрифта заголовка по умолчанию голубоватый и не зависит от того, какой задан в свойстве. Контролы, лежащие на GroupBox'ах (в т.ч. на вложенных) принимаю цвет родителя только после сворачивания формы в редакторе и разворачивании, но цвет шрифта самого GroupBox'а не меняется вообще.

Кстати, достаточно один раз поменять у формы параметр шрифта, чтобы весь шрифт на всех контролах стал таким каким и надо. И вложенные GroupBox'ы отображаются нормально.

Имхо надо убирать DefaultFont и все, что с ним связано. С тех пор как его ввели - шрифты все испортились. Раньше я не припомню никаких проблем со шрифтами. Что задал, то и получил. А теперь какой-то кошмар. До сих пор не понимаю зачем его ввели.


DKOL   (24.03.17 07:29[63]

Хмм.. у меня не помогло.. групбокс внутри групбокса все равно имеет корявый заголовок http://keep4u.ru/image/SQhxq


Dimaxx ©   (24.03.17 23:56[64]

У меня Д7. Возможно проблема в ТурбоДельфи и возможно неправильное наследование ParentFont.


PrnZ   (12.04.17 05:14[65]

[62] Имхо надо убирать DefaultFont и все, что с ним связано. С тех пор как его ввели - шрифты все испортились.

to:Dimaxx - а чего тебе мешает допустим в INITIALIZATION это делать? или в FormBeforeCreate? Не, DefaultFont нужен.  (Хотя в FormBeforeCreate можно и обойтись - SystemParameterInfo+CreateFontIndirect - обычно так и делаю). В каком смысле - испортились? Ну ставь 5 в LOGFONT.__Quality (или как её там).

to:DKOL - да, есть такое. похожий эффект можно получить если положить тулбар на эдитбокс (делал чтото типа вистаэдитдир).


Dimaxx ©   (12.04.17 22:57[66]

>> В каком смысле - испортились?
В том, что задаешь шрифт, а получаешь черти что - размер не тот. Раньше такого не было - какой задал шрифт, такой и получил.


Vladimir Kladov ©   (25.04.17 20:21[67]

Кто-то захватил kolmck.net и постит там что пожелает. Предупреждаю: к этому ресурсу я не имею никакого отношения. На данный момент зеркало прежнего kolmck на сайте kolmck.ru. Есть репозиторий на sourceforge:
https://sourceforge.net/projects/keyobjectslibrary/


dmk ©   (27.04.17 19:09[68]

>https://sourceforge.net/projects/keyobjectslibrary/
По этой ссылке архив с EXE. Там нет никакой библиотеки.


Vladimir Kladov ©   (28.04.17 14:27[69]

Меня направляет правильно:
http://savepic.ru/13754280.png

В крайнем случае, можно просто зайти на sourceforge.net и вбить в строку поиска
keyobjectslibrary или kolmck. Можно и просто kol, но тогда результат не первый.


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо