Конференция "KOL" » Будет ли работать сайт KolMck.net?
 
  • Sheleh (14.07.16 11:46) [0]
    Было очень удобно порой на него заглядывать. Если бы знал, что он исчезнет, наверное бы закачал его целиком заранее и захостил бы в виде зеркала. Если у кого осталось содержимое ресурса, буду рад, если поделитесь. Могу выложить на своем компе с именем вроде kolmck.ddns.net.
  • RusSun © (14.07.16 18:46) [1]
  • 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]
  • 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://pda.delphimaster.net/?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.
 
Конференция "KOL" » Будет ли работать сайт KolMck.net?
Есть новые Нет новых   [83210   +9][b:0.001][p:0.005]