-
Было очень удобно порой на него заглядывать. Если бы знал, что он исчезнет, наверное бы закачал его целиком заранее и захостил бы в виде зеркала. Если у кого осталось содержимое ресурса, буду рад, если поделитесь. Могу выложить на своем компе с именем вроде kolmck.ddns.net.
-
-
Фигасе! Я даже не знал, что бывает такой сервис.
-
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 .(
-
-
Остался ли у кого-то архив с компонентами Кладова для VCL? Архив назывался, если склероз не изменяет, KladovVCL.zip.
-
-
Премного благодарен!
-
Будет жить?
Или KOL умер??
-
Нынешний, вероятно, умер.
В КОЛе утечек памяти много - проверил на FPC. Код получается "грязный". КОЛ надо переписывать с объектов на классы. Немного увеличится размер, но будет проще. Плюс либо избавляться от асма совсем, либо дописывать варианты для 64 бит на асме.
-
>Плюс либо избавляться от асма совсем.
Солидарен. Много много лет назад я об этом говорил. Очень сложно поддерживать и синхронизировать библиотеку написанную на двух языках.
-
KOL задумывался как кодоэкономичная библиотека, классы добавят навороты и убавят экономичность. Но лично я, например, тоже не против избавления от асма.
-
На данный момент размер исполняемого файла всем пофигу. Я согласен с тем, что сложное приложение, имеющее размер COMMAND.COM это круто (и мне самому это нравится - что уж тут скрывать), но в данное время при наличии терабайтов на диске и 100мбит/1Гбит каналов связи размер мало имеет значения.
Классы добавят автоматическое удаление потомков и все связанное с этим. Упростится переделка сторонних компонент. Пропадут утечки памяти, связанные с постоянной работой с указателями на объекты. Появится полноценная возможность трассировки с просмотром любых значений свойств этих объектов (читай классов) - в данный момент отладчики D5/D7 (более старшие не пробовал) не могут полноценно работать с объектами (это мелочи). Немного улучшится кроссплатформенность - КОЛ несет в себе все, не требуя практически никаких доп. модулей, кроме стандартных. Я замучался адаптировать КОЛ под FPC - а когда он наконец-то заработал и я увидел, что творится в памяти - понял, что нуегонафик эти объекты. При всех этих достоинствах я соглашусь на некое увеличение кода. В FPC 3.0 в 32-битном режиме exe с пустой формой занимал примерно 31кб, в 64-битном - 47кб. Что все равно ГОРАЗДО лучше громадных VCL-приложений, которые растут как на дрожжах. Так что 16кб и 32кб в D5 - невелика разница.
-
В Delfi тоже утечки?
-
В Дельфи нет средства для контроля за утечками памяти.
-
> В КОЛе утечек памяти много - проверил на FPC
А где конкретно?
> В Дельфи нет средства для контроля за утечками памяти.
Есть отдельный memproof
Есть встроенный\и отдельно устанавливаемый FastMM
Есть madCollection...
Периодически смотрю - никаких утечек.. Поэтому неплохо бы конкретики
-
Сначала везде где есть создание объектов и выделение памяти (а также освобождение) поставил вывод в лог всего что, в каких кол-вах запрашивается и удаляется. Выяснилось, что объекты создаются дважды(!!). Мб это особенность FPC, но форма с меткой и кнопкой создает два объекта формы, 2 кнопки и 2 метки. Везде где есть Getmem/Freemem все создается и освобождается правильно. Но объекты создаются дважды, а удаляются 1 раз. Встроенная в FPC проверка на утечки этого же приложения в лог выдает - запрошено 11 областей памяти, освобождено 8 или 9 (не помню точно). Допускаю, что средство неверно работает с объектами, равно как и FPC может отличаться особенностями работы с объектами. Но нет никакой гарантии, что вышеприведенные средства для Дельфи гарантированно верно работают с объектами. В итоге "все хорошо, прекрасная маркиза" также могут быть и неверными данными.
-
Вполне возможно, что при развитии FPC что-то переделали, а об объектах банально забы(и)ли.
-
Объекты оставлены в режиме совместимости со старых версий. Это, емнип, частный случай класса в старых досовских турбо-паскалях и ныне считается как устаревший. В итоге отладчик ни в одной версии (новее бесплатного Turbo Explorer'а не проверял) не работает с ними корректно. Опять-таки, емнип, они есть, но их не рекомендуют использовать. Взято с этого же форума: object, в отличие от class, не требует обязательного выделения кучевой памяти для размещения экземпляра, поэтому экз-р object может быть автоматически создан компилятором в секции данных или в стеке, в зависимости от того где он объявлен. >> а об объектах банально забы(и)ли Это вряд ли. Тогда их просто выбросили бы, раз они устаревшие.
-
По автоматическому созданию объекта - это только для статического объекта. Утечек в этом случае по идее должно быть не больше чем от локальных\глобальных переменных.
-
Дело не в этом, это все лирика. Но ясно одно - нужно отказываться от асма полностью, и, желательно, от объектов.
-
> Выяснилось, что объекты создаются дважды(!!)
Интересная штука.. но у меня подозрение, что это происходит только в fpc.
А как воспроизвести? Только в формами\контролами такая штука или достаточно создать простой PStrList их будет два?
> поэтому экз-р object может быть автоматически создан компилятором
> в секции данных или в стеке, в зависимости от того где он
> объявлен.
На самом деле классная штука, объект может лежать просто на стеке... но увы..
> В итоге отладчик ни в одной версии (новее бесплатного Turbo
> Explorer'а не проверял) не работает с ними корректно.
А как проявляется? Просто о некоторых особенностях в курсе, например нельзя юзать default параметры или криво помощник кода отрабатывает, но это не про отладчик..
> Но ясно одно - нужно отказываться от асма полностью, и,
> желательно, от объектов.
Тут вот смотря как посмотреть...
Если есть желание юзать новые версии (выше упомянутой турбы, хотя.. даже на ней с классами будет чуть да удобнее), то классы удобнее.. но кода будет больше.. Но насколько помню из-за уродской архитектуры новых версий принудительно цепляется sysutils(это в тех, что смарел.. а в более новых мб и еще чего..)
Если есть желание юзать х64 - то тут только PAS_VERSION.. и опционально отказ от объектов..
А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..
И немного лирики насчет отказа от объектов в пользу классов:
1) Просто поменять object -> class - это вряд ли много работы будет.. Хотя уже от привычных List: PStrList/NewStrList надо будет отказаться в пользу List: TStrList/TStrList.Create
2) Или же полностью менять архитектуру на использование виртуальных методов
-
> А если до сих пор используется делфи7(или еще старее) - то какой смысл убирать рабочий асм код - не понятно..
Смысл в следующем. Если кто-нибудь решит исправить или дополнить версию на Паскале, то кто будет вносить изменения (дополнения) на Ассемблере.
-
Использовал объекты у себя через FPC без KOL, создаются один раз, никаких утечек. Так что не думаю, что имеет смысл отказываться от объектов.
-
> А как проявляется?
Проявляется, когда в пошаговом режиме наводишь, допустим, на используемый 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
Ключевое слово "без".
-
> Ключевое слово "без".
Я имею в виду, что проблема, если и есть, то в KOL, а не в object как таковых
-
> Form.Width и в подсказке вместо значения появляется либо
> Illegal value, либо AV (хотя значение там есть и верное).
> С классами такого нет. Д5-Д7 точно, про турбо не помню
> - мало юзал.
Конкретно данный пример отрабатывает в турбе нормально. А вот тот же проперти TStrList.Count показывает бред.. надо смотреть саму переменную fCount. Вообще не сильно удивлюсь если в новых версиях object выпилят полностью..
> По сравнению с VCL - прибавка мизерная. От VCL приложение
> пухнет активнее. Если правильно помню, то просто +1 юнит
> в приложении это уже +8...10кб лишнего кода, помимо кода
> самого юнита.
В том то и дело, что там цепляется sysutils, который тащит еще модули за собой.
> Зачем? Никто не мешает писать:
Так у меня такой же вопрос возникает, а зачем так писать?)
Когда уже перешли на классы и привычное написание будет как раз через "TClass.Create;"
> В коде много кода на асме без версий на паскале - для 64
> бит такой фокус не прокатит.
Когда собирал последний SVN, то насколько помню там компилировалось все в х64.. Да и не замечал, что есть кода чисто на асме без пас версии.
Если затевать какие то глобальные переходы, то нужно это делать поэтапно. Сначала одно, потом другое и т.д..
Вопрос кто будет это делать? Кому это реально надо? И что Владимир думает поэтому поводу..?
-
> там цепляется sysutils, который тащит еще модули за собой.
Он дает прибавку 40-50кб и ничего лишнего не тащит за собой. Основная масса кода - Classes, Forms, контролы. Вот там тащится все беспорядочно. Один Classes, емнип, таращит код на 200+ кб.
> привычное написание
Можно оставить обратную совместимость через условную компиляцию. Старый синтаксис уменьшит переделку уже написанного.
> делать поэтапно
Поэтапно не получится - там все завязано на всем.
> Вопрос кто будет это делать?
Вопрос открытый. Могу я, но мне, к примеру, нафик не нужен линух. Значит я выкину все к нему относящееся. Мне не нужна совместимость с тонной разных версий (меня интересует D5-D7 и FPC) - соответственно тоже выкину. Всяческие нагромождения под CommandActions и USE_FLAG также полетят в помойку. И т.д. и т.п.
> Кому это реально надо?
Вопрос также открытый. А надо ли это вообще? Меня не парит в D7 писать на VCL - размер exe там приемлемый. А вот если понадобится написать что-то коммерческое - у FPC exe жирнючий как свинья, но за полным отсутствием аналогов сойдет. Explorer - обрезок (сторонние компоненты поставить можно, но только в подписанный сигнатурой дефолтный пакет). Дельфи не подходит из-за отсутствия лицензии.
> И что Владимир думает поэтому поводу
Владимира, видимо, давно не волнует судьба КОЛ. Емнип, он его отдал на откуп общественности. Весной не отвечал даже на письма. Тут не появляется давно.
-
мне нужен КОЛ, но только для моего древнего навигатора. То есть размер поменьше и под 6-ой арм (кросскомпилятор Лазаруса умеет 4-ый). Для остального уже 5 лет есть C#
-
C# - это идеологически антипод KOL.
-
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;
старый участок памяти не освобождается, после выхода из функции переменная станет недоступной и вот вам утечка. Кто там говорил, что все проверял и нет утечек? Выкиньте свои устаревшие инструменты :).
-
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;
-
В который раз...
Есть архив сайта kolmck.net (не помню, раньше его выкладывал или нет) от 12.01.2014 года.
Посмотрю еще были еще архивы сайтов Тедди и как мне кажется более поздние архивы kolmck.net.
-
Dimaxx
По TBitmap.ReleaseHandle:
Там развязывание объектов (без удаления отвязываемого). DDB, при обнулении (отвязки) fHandle превращается в DIB с независимым fDIBBits (копией ранее привязанного объекта). А старый участок памяти остается с отвязанным объектом и удалеятся при необходимости вместе с ним.
По TBitmap.ClearData:
под fDIBBits память выделяется при NewDIBBitmap, при этом fHandle равно 0.
Если потом присвоить fHandle, то судя по TBitmap.SetHandle вроде последующая очистка памяти будет уже через fDIBHeader.
-
DeleteObject удаляет все связанное с хэндлом. Так что ClearData оправдана - там все верно.
-
Читал что не удаляет, а помечает как освобождённое. То есть после DeleteObject оно ещё лежит в памяти неопределённое время.
-
Забыл, для тех кто не заметил соседнюю тему (или на случай если она потеряется): "Поднято зеркало прежнего сайта по адресу http://kolmck.ru" © Vladimir Kladov
-
Dimaxx
из KOLBook по TBitmap
числе, для изображений, зависящих от устройства);
Handle - дескриптор системного графического объекта типа hBitmap. Независимые от устройства изображения не нуждаются в наличии такого дескриптора, и вообще всю работу потенциально могут выполнять без выделения такого дескриптора. Однако, если идет работа с изображением через канву, дескриптор для изображения создается автоматически. Допускается присваивать этому свойству в качестве значения дескриптор битового изображения (типа hBitmap), полученный любым способом, в том числе из API-функций - при этом прежнее изображение теряется и замещается присвоенным, а объект становится "владельцем" присвоенного дескриптора (т.е. дескриптор будет автоматически разрушаться вместе с объектом в его деструкторе);
> ReleaseHandle - отделяет дескриптор от изображения, освобождая
> его (независимое от устройства изображение продолжает при
> этом существовать в памяти, и при необходимости выполнения
> каких-либо операций, требующих наличия дескриптора, тот
> будет выделен снова). Отделенный в результате такой операции
> дескриптор освобождается в том смысле, что с этого момента
> он не известен (и не интересен) объекту TBitmap. И тогда
> уже вызывающий код отвечает за его дальнейшую судьбу. Например,
> он может быть удален API-функцией DeleteObject, или использован
> каким-либо еще способом. Важно лишь обеспечить отсутствие
> утечек таких ресурсов: все выделенные ресурсы GDI, к которым
> относится и hBitmap, должны быть обязательно удалены, когда
> надобность в них отпадает;
поэтому и там все верно.
-
сорри за форматирование.
-
> В который раз...
> Есть архив сайта kolmck.net (не помню, раньше его выкладывал
> или нет) от 12.01.2014 года.
> Посмотрю еще были еще архивы сайтов Тедди и как мне кажется
> более поздние архивы kolmck.net.
Доброе время суток.
Напишите мне или выложите ссылку в этой теме.
Особенно интересны архивы сайтов Тедди так сейчас их не найти. Спасибо.
-
-
-
> вроде. что ещё у него могло быть?
Что могло быть знает Гость. ... были же и более ранние, которые после не выкладывались. через 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.
-
Что-то пытаюсь отправить сообщение - и не выходит. Молча открывается корень ветки и всё... Не понятно из-за чего... Так, а если ток последние два предложения... На данный момент входить надо по такой ссылке: http://web.archive.org/web/20161206042443/http://kolmck.ru/index.htmlЯ основные страницы уже сохранил, остальное не знаю как автоматом делать, руками будет долго и с ошибками...
-
У кого есть доступ для правок к 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 ); <--- без этой строки - утечка
-
kolmck.ru - это свежевыложенное зеркало, для доступа к нему не нужна машина времени. Старая версия - это kolmck.net.
-
Выложенный код на 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, А как лучше то? Не использую фпц, нет возможности проверить
-
В варианте Thaddy можно использовать и старые версии FPC. Ток в вышенаписанном мною забыл добавить после {$DEFINE _D7orHigher} строки
{$DEFINE _D2005orHigher}
{$DEFINE _D2006orHigher}
{$DEFINE _D2007orHigher}
-
Кстати, в свое время Владимир говорил про то, что приходилось выбрасывать лишнее в KOLadd из-за того, что KOL.pas превышал 65к строк. Так вот KOL.pas надо основательно почистить - там море пустых строк, закомменченного кода + последовательное объявление переменных в объектах одинакового типа можно свести в одну строку. Ну и желательно отформатировать код для аккуратного вида.
-
Dimaxx, добавил вариант от Thaddy(без проверок), чтоб можно было и старые версии использовать.
Выкинуть мусор и отформатировать код было бы не плохо.. Но, например, для меня:
> последовательное объявление переменных в объектах одинакового типа можно свести в одну строку.
и
> отформатировать код для аккуратного вида
Взаимоисключающие вещи :)
-
> Dimaxx, добавил вариант от Thaddy(без проверок), чтоб можно
> было и старые версии использовать.
{$MODE DELPHI} и {$ASMMODE INTEL} надо добавлять обязательно - не компилируется.
> Взаимоисключающие вещи :)
Ну так приходится чем-то жертвовать. Кстати, там в некоторых местах в record'ах так уже сделано.
-
> надо добавлять обязательно
Добавил, будет время - проверьте
> Ну так приходится чем-то жертвовать. Кстати, там в некоторых
> местах в record'ах так уже сделано.
Сейчас общий вид форматирования представляет кашу.. Да и редактор кода тупит для KOL.pas
-
Неверно работает свойство контрола AnchorBottom, если он лежит, к примеру, на GroupBox - по идее должен привязываться к границе родителя (GroupBox), а он привязывается к форме. В итоге нижняя граница контрола находится на уровне нижней границы GroupBox.
К сожалению в анчорах не силен, поэтому как поправить не знаю.
-
A AnchorRight работает верно, но увеличивает ширину на лишние 2 пикселя.
-
Вдогонку: непонятно как работает создание контрола - настраиваю шрифт у KOL-формы и шрифт по умолчанию у KOLProject. Кидаю на форму GroupBox - он наследует шрифт формы. Кидаю кнопку или метку - шрифт другой. Хотя в дизайнере шрифт верный и все верно отображает.
-
> Неверно работает свойство контрола AnchorBottom, если он
> лежит, к примеру, на GroupBox - по идее должен привязываться
> к границе родителя (GroupBox), а он привязывается к форме.
> В итоге нижняя граница контрола находится на уровне нижней
> границы GroupBox.
А есть ли такой же баг если использовать Panel вместо GroupBox.
У GroupBox есть еще глюк со шрифтом - если в GroupBox кинуть другой GroupBox то шрифт искажается
-
То то я думаю, что за фигня. Пишу альтернативу explorer.exe Екзешник маленький 72Кб, а памяти отжирает 40 мб. Надо было изучать С https://yadi.sk/d/N1zyD3fpfSQAG
-
KOL жрет столько же, сколько и VCL. Доп. отжирание зависит от запросов в коде. И не факт, что тот же код на Си будет жрать меньше.
-
>> А есть ли такой же баг если использовать Panel вместо GroupBox.
Если не уменьшать до 0 размер панели, то нет. При изменении размера панели до 0 после обратного увеличения нижняя граница контрола на панели уезжает до нижней границе панели. А после нескольких произвольных изменений до 0 и обратно нижняя граница панели вообще съезжает до нижней границе формы.
PS: Изменение размеров происходит изменением размеров формы - все Anchor'ы панели True, Anchor'ы контрола внутри также все True.
-
Мда.. GroupBox совсем глючный..
Проверьте еще есть ли баг со шрифтом - берем GroupBox, на него кидаем другой GroupBox и смотрим их Caption'ы, не исказился ли шрифт?
-
Со шрифтом все интересно. Он наследуется от формы, но размер почему-то свой, отличный от размера шрифта формы. Но! Достаточно поменять стиль шрифта программно у всей иерархии GroupBox - Font.FontStyle:=[] (или, например, размер шрифта) и тут же весь шрифт (включая все контролы, которые лежат внутри GroupBox) становится в точности как у формы. Даже у вложенных GroupBox'ов. Только менять параметры шрифта надо у всех GroupBox'ов - у тех, у кого не поменяем параметры шрифта останутся прежними, включая все контролы внутри GroupBox'ов. Точно также и у формы - пока не поменяем у нее какое-нибудь свойство шрифта, не меняется, хотя в редакторе все шрифты выставляются в точности с указанными. Плюс у GroupBox'а почему-то в редакторе цвет шрифта заголовка по умолчанию голубоватый и не зависит от того, какой задан в свойстве. Контролы, лежащие на GroupBox'ах (в т.ч. на вложенных) принимаю цвет родителя только после сворачивания формы в редакторе и разворачивании, но цвет шрифта самого GroupBox'а не меняется вообще.
Кстати, достаточно один раз поменять у формы параметр шрифта, чтобы весь шрифт на всех контролах стал таким каким и надо. И вложенные GroupBox'ы отображаются нормально.
Имхо надо убирать DefaultFont и все, что с ним связано. С тех пор как его ввели - шрифты все испортились. Раньше я не припомню никаких проблем со шрифтами. Что задал, то и получил. А теперь какой-то кошмар. До сих пор не понимаю зачем его ввели.
-
-
У меня Д7. Возможно проблема в ТурбоДельфи и возможно неправильное наследование ParentFont.
-
[62] Имхо надо убирать DefaultFont и все, что с ним связано. С тех пор как его ввели - шрифты все испортились.
to:Dimaxx - а чего тебе мешает допустим в INITIALIZATION это делать? или в FormBeforeCreate? Не, DefaultFont нужен. (Хотя в FormBeforeCreate можно и обойтись - SystemParameterInfo+CreateFontIndirect - обычно так и делаю). В каком смысле - испортились? Ну ставь 5 в LOGFONT.__Quality (или как её там).
to:DKOL - да, есть такое. похожий эффект можно получить если положить тулбар на эдитбокс (делал чтото типа вистаэдитдир).
-
>> В каком смысле - испортились?
В том, что задаешь шрифт, а получаешь черти что - размер не тот. Раньше такого не было - какой задал шрифт, такой и получил.
-
Кто-то захватил kolmck.net и постит там что пожелает. Предупреждаю: к этому ресурсу я не имею никакого отношения. На данный момент зеркало прежнего kolmck на сайте kolmck.ru. Есть репозиторий на sourceforge: https://sourceforge.net/projects/keyobjectslibrary/
-
-
Меня направляет правильно: http://savepic.ru/13754280.pngВ крайнем случае, можно просто зайти на sourceforge.net и вбить в строку поиска keyobjectslibrary или kolmck. Можно и просто kol, но тогда результат не первый.
-
Кто-то захватил kolmck.ru, и постит там, что пожелает. Хотел скачать модуль math, а не тут то было (
-
-
AL-IV это тоже моя разработка. Я по ошибке залил обновление в корень сайта. Сейчас исправил. Извиняюсь за неудобства.
-
-
Может у хостера антивирусник на демо-kol-файлы среагировал?
-
-
YOUR HOSTING
HAS BEEN SUSPENDED
ВАШ ХОСТИНГ
БЫЛ ПРИОСТАНОВЛЕН
-
-
Владимир, прошёл слух, что Вы разрабатываете что-то новое по принципу KOL. Правда ли это?
-
Все на сайте. http://kolmck.000webhostapp.com/AL4/index_ru.htm и https://sourceforge.net/projects/al-ivAL-IV (Алфор) - язык программирования, с возможностью компилироваться в другие языки. До некоторых пор я поддерживал C++ (gcc/msvc), java, python. Потом их выбросил, и оставил только c#/Delphi/FPC. В том числе, код может компилироваться в Delphi/KOL, при этом получается (обычно) в несколько раз меньше (даже вдвое меньше, чем в C#). При этом запускается под всеми версиями Windows. Вариант c компиляцией в Free Pascal/LCL самый большой, и чуть подтормаживает, но может уже сейчас в Linux без wine (а потенциально и много еще куда, но потом).
|
Есть новые 
Нет новых [134427 +26][b:0.001][p:0.002]