Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Schooler © (2005-11-01 11:38:00)
Уважаеммые Мастера!

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

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

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

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

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

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

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

Igorek (2005-11-15 14:44:00) [1]

> Schooler (15.11.05 10:01) [29]

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

Schooler (2005-11-15 10:01:00) [2]
To Igorek ©

> какой он будет в данной ситуации

Igorek (2005-11-13 16:08:00) [3]

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

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

Schooler (2005-11-09 10:25:00) [4]
To Igorek ©

> Не знаешь что такое стек?

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

Igorek (2005-11-08 19:39:00) [5]

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

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

Schooler (2005-11-08 17:03:00) [6]
То Igorek ©

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

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

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

Igorek (2005-11-08 09:09:00) [7]

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

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

Igorek (2005-11-07 13:09:00) [8]

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

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

Igorek (2005-11-07 13:05:00) [9]

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

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

Schooler (2005-11-07 12:54:00) [10]
Вот ежели
> код редактора не попадет в ран-тайм пакет

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

Igorek (2005-11-07 12:11:00) [11]

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

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

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

Schooler (2005-11-07 09:58:00) [12]
To Igorek ©

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

Igorek (2005-11-03 16:27:00) [13]

> Schooler (03.11.05 16:09) [17]

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

Schooler (2005-11-03 16:09:00) [14]
В самом простом случае Edit становится частью Label ?

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

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

Igorek (2005-11-03 14:55:00) [15]

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

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

Schooler (2005-11-03 13:39:00) [16]
То 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 10:34:00) [17]
WYSWYG, кстати - это сам принцип Делфи - то что, редактируете в дизайнере формы - то же получаете в рантайм.

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

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

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

GuAV (2005-11-02 22:26:00) [18]
Такое есть, например для TPageControl PageIndex.

Юрий Зотов (2005-11-02 22:17:00) [19]
> Igorek © (02.11.05 20:47) [11]

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

Igorek (2005-11-02 20:47:00) [20]
Думается можно такое "редактирование на месте" реализовать по правильному.
Вообще это разделение дизайн-тайм и ран-тайм код имхо не всегда четкое. В моей практике были прецеденты..

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »