nesco, нижняя точка Time всегда содержит время запуска программы. Было бы более правильно(?),чтобы там было текущее (системное) время.

Tad, хорошо, что сказал, спасибо

nesco, но только в режиме выбора даты, при свойстве Time->True не нужно !

[size=-2]------ Добавлено в 19:31
И ну никак не пойму - зачем нужен CheckBox

Tad, а причем здесь вообще системное время, и визуальный контрол
Чтобы в консольной программе узнать таковое нельзя было

[size=-2]------ Добавлено в 19:43
Или опять идеи "мультипроцессорности" покоя не дают

Предложена идея убрать. Зачем дело встало -- уберем (я тоже не понял нафиг он нужен -- лишний гемморой)

А что плохого если я в режиме "Дата" смогу считать текущее время, а не время запуска программы? Конечно для этих целей есть компонент Time, который устроен по идее "мультипроцессорности"- вполне можно было разделить на Дату и Время.
А могу вообще в Edit заносить и Дату и Время вручную.

Чистая логика: такой "аргумент" применим к любому компоненту.

И, следовательно, таковым не является

Кстати, дата и время - неразделимы.

Galkov, глянь, если не сильно занят. Я убрал класс PPicker и напрямую назначил контрол. Все работает, кроме выдачи события. Никак не могу его прицепить (цвета, пока, нет, но это -- детали)

Galkov, не надо передергивать. При чем тут элемент Convertor?
Мысль я понял: в Delphi так, как сейчас работает наш DatePicker, поэтому ничего менять не надо.
продолжу - ведь никто так не делает - тоже не аргумент.
Если б Dilma прислушивался к таким "аргументам" не было бы HiAsma.
Проще всего зарубить идею на корню - потребовать аргументы. Нет у меня аргументов, но есть желание иметь на нижней точке (по запросу) живое время.
Так, что давай аргументы, - а почему нет?
, невероятно, но ( кстати) я тоже это знаю.
Нет - значит нет.

Tad, вы дольше полемику будете разводить, чем я его сделаю. Будет это свойство, я о нем тоже думал. Кто не будет использовать DatePicker для определения текущего времени, тот будет использовать Time. Кто, чего желает, тот то и использует

nesco, кто развел полемику ?
Я предложил и сказал для чего. Если бы на это предложение было сказано, что "Этого нельзя делать потому-то, потому-то и потому-то" - все бы на этом и закончилось.

Честно, я тоже не понял -- почему? Вроде, компонент специально для этих целей и сделан.

nesco, слухай сюды:

1) Вот мне интересно, сколько ты еще мозги компостировать будушь со всякими HiAsmFont2KolFont. В share давно определена (и не просто определена, а используется) _hi_SizeFnt. Причем делает это более правильно.

2) Не считая того, что в Init вызывать inherrited - обязательно

3) Убери поле fHandle вообще, и везде говори Control.Perform

4) Оконная ф-я читает поле Control.Tag и пляшет от него. Так установи его (в Init) в нужное тебе значение (вообще-то это Self)
И вызывай там сразу _event__OnChange без всяких проверок, тройных вызовов и листаний поинтеров.

А я откуда знал, вот теперь буду знать.
Хм. Но это не преобразователь типов -- PFontRec --> PGraphicTool. Меня это совсем не устраивает. Мне был нужен именно преобразователь.

[size=-2]------ Добавлено в 12:13

Ну а тогда в FontBox'e зачем Killer стоит вместе с Add2AutoFree?

[size=-2]------ Добавлено в 16:10
Galkov, ни фига у меня не получается без бубна. Вот смотри -- рабочая бета версия, но с бубном. Да, кстати, что будем делать с хинтом, предложенный Dilm'ой фикс не спасает -- утечка ресурсов продолжается. Без хинта утечка по динатесту -- нулевая.

[size=-2]------ Добавлено в 16:25
И еще. Непонятен вопрос с двойным обращением к нотификатору с одним и тем же запросом (в оригинале тоже два события выдавало). И пес знает, как это победить?

А бестолковка на что - задаешь себе вопрос: как это делают другие элементы?
Смотришь, сравниваешь, если не нравится выступаешь с предложениями по изменению.
Что и сделал коллега tsdima, и (обрати внимание ) все это есть на форуме


Необходимо было произвести уничтожения объектов при ЖИВОМ контроле. У тебя есть такая необходимость


Это не информация


Не кстати