Редакторы свойств и редакторы компонентов + WYSWYG

← →
Schooler (2005-11-01 11:38) [0]

Уважаеммые Мастера!

Вот такой вопрос.

Редакторы свойств-классов и редакторы компонентов обычно оформляются в виде показа Модального окна.

Можно ли сделать так(правильно ли это, и т.д. и.т.п.), чтобы свойство редактировалось на самом копмоненте в design-time.

Например: у наследника TDBGrida имеется свойство-класс Headers (Иерархические заголовки столбцов).
Я оформил редактор свойства через TTreeView на модальной форме.

1.При вызове редактора его форма стандартно висит на переднем плане. Неплохо было бы редактировать свойство в области заголовков столбцов.

2.Разница отображения иерархии в момент редактирования свойства
и конечный результат на Gride значительны и наводят на мысли о WYSWYG.

Может, кто-нибудь проделывал подобное, поделитесь своим опытом.
На что следует заменять код типа TMyClassPropertyEditorForm.ShowModal?

← →
Igorek © (2005-11-01 12:54) [1]

- можно выводить редактор немодально
- если помещать средства редактирования свойств прямо на компонент и прятать их в ран-тайм, то получится, что в ран-тайм будет ненужный код; а обычно дизайн-тайм код не линкуется в конечный проект

← →
Schooler (2005-11-01 13:28) [2]

To Igorek ©

> выводить редактор немодально

Не очень Вас понял. Можно, конечно. Но какие возможности это привнесет?

> то получится, что в ран-тайм будет ненужный код

И я про то же :-(

← →
Юрий Зотов © (2005-11-01 15:10) [3]

Поместите на форму редактора дубль Grid"а и редактируйте его, а при нажатии кнопки ОК переносите изменения в рабочий компонент (соответственно, при нажатии кнопки Cancel изменения не переносятся). Вот и получится WISIWIG.

← →
Schooler (2005-11-01 16:18) [4]

To Юрий Зотов ©

Хотел написать "Абсолютно Вас не понял...".
Как вариант, я такой подход рассматривал.

Ну а что касается
> редактировать свойство в области заголовков столбцов
?

Никак не получится без
> помещать средства редактирования свойств прямо на компонент
> и прятать их в ран-т

?

← →
Юрий Зотов © (2005-11-01 16:42) [5]

Непонятно, что означает "помещать средства редактирования свойств прямо на компонент". Уточните.

← →
Schooler (2005-11-01 18:08) [6]

To Юрий Зотов ©

Например, для редактирования текста Fixed-ячейки Grida в design-time использвать Edit помещенный на сам Grid. Я так понимаю.

← →
Юрий Зотов © (2005-11-02 03:06) [7]

> Schooler (01.11.05 18:08) [6]

А какая разница?

← →
Igorek © (2005-11-02 10:50) [8]

> Юрий Зотов © (02.11.05 03:06) [7]
> > Schooler (01.11.05 18:08) [6]
> А какая разница?

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

← →
Schooler (2005-11-02 13:03) [9]

To Юрий Зотов © & Igorek ©

Блин, теперь я вас обоих не понимаю :)

Хорошо, пусть это называется "редактирование на месте".
Я , конечно, несколько вольно использовал термин WYSWYG, но, кажется Вы (Igorek ©) меня поняли.

И в этом контексте "редактирование на месте" не исключает, а скорее приближает "что видите, то и получаете".

Если я понятно выразился, то остается проблема: Средство редактирования становится частью Компонента. Так?

← →
Igorek © (2005-11-02 15:20) [10]

> Если я понятно выразился, то остается проблема: Средство
> редактирования становится частью Компонента. Так?

Если оно не используется в ран тайм - то так.

← →
Igorek © (2005-11-02 20:47) [11]

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

Итак, возьмем для простоты компонент типа TLabel.
У него есть св-во Text: String, которое редактируется в инспекторе.
Мы хотим, что-бы пользователь в дизайн-тайм как-то там кликнул на компоненте (напр. правой, потом пункт меню EditText). В этот момент на лейбе появляется эдит-бокс, пользователь вводит значение, нажимает ентер и лейба меняет текст.

У нас из дизайн тайм кода есть выход на компонент. В момент выбора пункта меню EditText - мы создаем эдит-бокс, кладем его на компонент, переводим на него фокус ввода.
У компонента перед этим запрашиваем клиентские координаты, по которым пометить эдит-бокс.
Также перед этим подписываемся на событие OnKeyPress.
Пользователь вводит текст... и нажимает энтер (ну или потеря фокуса) - в нашем обработчике извлекаем значение текста из эдит-бокса, запихиваем в лейбу и посылаем нашему компоненту сообщение (через PostMessage!), получив которое он уничтожит эдит-бокс (в аргументах сообщения надо передать указатель). Можно чуть иначе - в компоненте предусмотреть св-во аля "указатель на внешний редактор", которое ссылается на эдит-бокс (тип поабстрактнее - виртуальный деструктор все же). Его устанавливать перед выходом из процедуры обработчика нажатия меню.
Тогда можно просто послать компоненту сообщение "Удали внешний редактор" - он его удалит и обнулит ссылку.

← →
Юрий Зотов © (2005-11-02 22:17) [12]

> Igorek © (02.11.05 20:47) [11]

Все это так, но возникает вопрос - зачем такие странные телодвижения, если можно сделать абсолютно то же самое, просто создав форму редактирования с тем же самым Edit"ом и кнопками ОК и Отмена.

← →
GuAV © (2005-11-02 22:26) [13]

Такое есть, например для TPageControl PageIndex.

← →
Igorek © (2005-11-03 10:34) [14]

WYSWYG, кстати - это сам принцип Делфи - то что, редактируете в дизайнере формы - то же получаете в рантайм.

> Юрий Зотов © (02.11.05 22:17) [12]
> > Igorek © (02.11.05 20:47) [11]
>
> Все это так, но возникает вопрос - зачем такие странные
> телодвижения, если можно сделать абсолютно то же самое,
> просто создав форму редактирования с тем же самым Edit"ом
> и кнопками ОК и Отмена.

Можно конечно.. И в инспекторе можно.. И в редакторе компонента.. Или как в ранних ВизуалСтудио обработчики вешаются - через десятые окна и визарды..

Но суть как раз в Edit in Place. Т.е. сразу видно, как текст будет выглядеть (шрифт едитбокса должен совпадать с шрифтом лейбы).
Кроме того модальные окна - тот еще гем.. Сколько раз бывало - редактируешь в окне, надо что-то посмотреть, а окно не дает..

← →
Schooler (2005-11-03 13:39) [15]

То Igorek © (02.11.05 20:47) [11]

Принцип понятен.

Можно поподробнее (желательно кодом) про?

> в компоненте предусмотреть св-во аля "указатель на внешний
> редактор", которое ссылается на эдит-бокс (тип поабстрактнее
> - виртуальный деструктор все же).

Юрий Зотов © (02.11.05 22:17) [12]

> зачем такие странные телодвижения

1. Ответ в Igorek © (03.11.05 10:34) [14]

2. Здесь рассматриваем пример с Label : необходимость такого подхода (Inplacce Editing) не очень уж очевидна.
У меня же еще более критичный ситуация (см. ворпрос): оцените визуальное отличие TreeView и иерархических заголовках для Грида. Что называется "почувствуйте разницу" :)

← →
Igorek © (2005-11-03 14:55) [16]

> Можно поподробнее (желательно кодом) про?
> > в компоненте предусмотреть св-во аля "указатель на внешний
> > редактор", которое ссылается на эдит-бокс (тип поабстрактнее
> > - виртуальный деструктор все же).

Код не дам. :)
Нету времени писать.
Ежели что непонятно - пиши как ты это понял, подправим..

← →
Schooler (2005-11-03 16:09) [17]

В самом простом случае Edit становится частью Label ?

TMyUglyLabel = Class(TLabel) private ExternalEditor:TEdit;// internal link for external PropertyEditor ..... end;

Я такое где то видел, это и вызывает у меня недоумение.
Я по другому не знаю как: мозги уже завернулись :(
Знал бы - не спрашивал!

← →
Igorek © (2005-11-03 16:27) [18]

> Schooler (03.11.05 16:09) [17]

Да, так, только или паблик или св-во и метод записи. Лейба его никогда не создает. Только ее обработчик соотв. пользовательского сообщения его удаляет и обнуляет ссылку. И тип лучше вообще TObject.

← →
Schooler (2005-11-07 09:58) [19]

To Igorek ©

Так то оно так, да только, видишь ли, этот редактор стал частью компонента (в виде ссылки), чего не происходит при стандартном подходе : вот это меня и не устраивает:(

← →
Igorek © (2005-11-07 12:11) [20]

> Так то оно так, да только, видишь ли, этот редактор стал
> частью компонента (в виде ссылки), чего не происходит при
> стандартном подходе : вот это меня и не устраивает:(

Ничего подобного.
1) код редактора не попадет в ран-тайм пакет
2) компонент никогда сам не создает редактор - это просто ссылка
3) не устраивает ссылка - читай еще раз:

> посылаем нашему компоненту сообщение (через PostMessage!
> ), получив которое он уничтожит эдит-бокс (в аргументах
> сообщения надо передать указатель).

← →
Schooler (2005-11-07 12:54) [21]

Вот ежели
> код редактора не попадет в ран-тайм пакет

, то это есть хорошо.
Тогда какие аргументы против такой методы есть, т.е. почему так делают, ну скажем, довольно редко ?

> Тогда какие аргументы против такой методы есть, т.е. почему
> так делают, ну скажем, довольно редко ?

1) это не вписывается в идеологию Делфи (инпектор+редактор компонента+редактор св-ва)
2) не так-то это очевидно и просто

> какие аргументы против такой методы есть

кроме того если так и делать, то без глюков - иначе лучше вообще не делать

> > посылаем нашему компоненту сообщение (через PostMessage!
> > ), получив которое он уничтожит эдит-бокс (в аргументах
> > сообщения надо передать указатель).

Можно вообще обойтись без указателя в компоненте и без обработчика в нем. Зачем нам все это - для уничтожения обьекта, метод которого находится в стеке вызовов.
Проще и лучше - это завести в пакете некий долгоживущий обьект-синглтон, который при создании затребует хендл у системы. Этому "уничтожителю" и посылать сообщения - "Удали обьект ХХХ".

← →
Schooler (2005-11-08 17:03) [25]

То Igorek ©

Блин, ну Ты и завернул!
Если не трудно, как вообще
>уничтожить обьект, метод которого находится в стеке
> вызовов

Это где копать, подскажи, вообще ума не приложу ?

В любом случае, Спасибо!

> Если не трудно, как вообще
> >уничтожить обьект, метод которого находится в стеке
> > вызовов
>
> Это где копать, подскажи, вообще ума не приложу ?

А что там копать? Эдит бокс вызывает твой обработчик (для события изменение текста). Т.е. в стеке висят его методы. И в своем обработчике ты должен этот эдит удалить. Но для безопасного удаления нужно сделать "отложеное уничтожение". Что непонятно? Не знаешь что такое стек?

← →
Schooler (2005-11-09 10:25) [27]

> Угу, в данном контексте конечно :(

Не знаешь что такое стек вызовов? Или какой он будет в данной ситуации? Или почему мы должны делать отложеное уничтожение?

← →
Schooler (2005-11-15 10:01) [29]

> Schooler (15.11.05 10:01) [29]

-обработчик OnKeyDown эдита, код находится в дизайн-тайм пакете //здесь надо удалить эдит контрол
-код эдита //но методы эдита висят в стеке
-процедура которая вызвана по клику на пункте меню

Редакторы свойств и редакторы компонентов + WYSWYG Найти похожие ветки