Есть ли будущее у DELPHI?

Цитата --Ins-- @ 27.03.12, 13:01

А в .NET с TAction или чем-то подобным как?

А это что за класс такой, а то гугл как-то пространно рассуждает на тему

Цитата --Ins-- @ 27.03.12, 13:36

DesweR, хе, это в XE2 фишка? Не знал не знал...

Да, this is LiveBindings

Добавлено 27.03.12, 13:48
korvin
А вот если мне понадобится для пары-тройки собственных компонентов обеспечить какую-нибудь свою специфичную "связь", ну хотя бы задача минимум: чтобы компоненты Foo, Bar и Baz могли "найтись" и "связываться" друг с другом (только друг с другом).
Xcode/IB такое позволит?

Цитата DesweR @ 27.03.12, 13:30

procedure TForm1.Edit2Change(Sender: TObject);
begin
  BindingsList1.Notify(Edit2, 'Text');
end;

Прикреплённая картинка

Это совсем не то, что требовалось, если ты не понял. И как-то все ну очень сложно/перегружено выглядит.

Цитата korvin @ 27.03.12, 13:57

Это совсем не то, что требовалось, если ты не понял. И как-то все ну очень сложно/перегружено выглядит.

что требовалось, то и выполнилось.
хоть это очень сложно

Цитата kanes @ 27.03.12, 13:37

А это что за класс такой, а то гугл как-то пространно рассуждает на тему

А ты же вроде дельфист был в девичестве (я не путаю), не знаешь? Смысл такой: допустим у меня есть некоторая форма, у нее меню и тулбар, другие компоненты. Причем команды меню и тулбара как часто бывают друг друга дублируют. С помощью данного класса я могу каждой кнопке или пункту меню назначить действие при щелчке и чтобы эти кнопки или меню автоматически обновляли свое состояние (Enabled, Checked, Caption) в зависимости от некоторых условий. Например, для кнопки и для пункта меню 'Save as', я могу в design-time назначить действие, код метода Execute которого сохраняет документ, а код метода Update присваивает свойству Enabled значение Document <> nil; В результате у меня кнопка и пункт меню всегда автоматически будут в актуальном состоянии, при щелчке на них выполнится нужный код.

Действия TAction могу быть произвольными (разработчик сам реализует их код Execute и Update) и стандартными - последние часто входят в состав пакетов компонентов кроме самих компонентов, так же регистрируются в среде и доступны в design-time.

Сообщение отредактировано: --Ins-- - 27.03.12, 14:08

Цитата --Ins-- @ 27.03.12, 14:03

А ты же вроде дельфист был в девичестве (я не путаю), не знаешь?

был, не сталкивался

Цитата kanes @ 27.03.12, 14:10

был, не сталкивался

Да ну нафиг Как же ты писал гуи-программы? Вопрос риторический

Добавлено 27.03.12, 14:21
Ну так эта, как там в .NET принято обрабатывать щелчки по меню/кнопкам и обновление состояние кнопок? Не холивара ради, действительно хочется знать

Сообщение отредактировано: --Ins-- - 27.03.12, 14:21

Цитата DesweR @ 27.03.12, 14:00

что требовалось, то и выполнилось.
хоть это очень сложно

Нет, требовалось связать несколько видов с одной моделью, ты же связал несколько видов между собой. Причем без кода не обошлось.

korvin, а ты уверен что хочешь видеть модель в dfm? Мне бы такое не понравилось

Цитата DesweR @ 27.03.12, 13:39

А вот если мне понадобится для пары-тройки собственных компонентов обеспечить какую-нибудь свою специфичную "связь", ну хотя бы задача минимум: чтобы компоненты Foo, Bar и Baz могли "найтись" и "связываться" друг с другом (только друг с другом).
Xcode/IB такое позволит?

А почему нет? Но ты как-то ты расплывчато описал. Когда они должны "найтись"? В design-time? А если объект создается в рантайме? Если у нас несколько объектов Foo с какими из них должны связаться объекты Bar и Baz? Со всеми? Как на Делфи это делается?

Добавлено 27.03.12, 14:50

Цитата --Ins-- @ 27.03.12, 14:34

korvin, а ты уверен что хочешь видеть модель в dfm? Мне бы такое не понравилось

Эм... в каком смысле? А ничего, что связи между Button и Action записываются в dfm? Ну допустим Action не модель, а контроллер. А связи между DBGrid и DataSet куда по-твоему записываются? Ты не забывай, что dfm -- это же просто сохраненное состояние компонента. Не обязательно визуального. Или у вас модель не может быть компонентом? А DataSet тогда что? А DataModule -- это модель или контроллер? Или что?

Что то вы в какие то дебри залезли. Вот в Qt такая система используется в основном для избежания кодирования по интерфесной части в тех местах, где это не касается логики приложения. Вот допустим есть диалог с параметрами и кнопочка "more". Нажимаешь кнопочку -- появляются расширенные настройки. Влияет это как нибудь на модель? Никак не влияет, просто показывает, или скрывает часть элементов по желанию пользователя. Т.е. абсолютно замкнутая на GUI операция. Вот есть Qt Creator. Значит накидываешь туда фрейм с основными настройками, фрейм с дополнительными настройками, пару рюшечек для автоформатирования (забыл как называются), даже наверное одной хватит. Фрейм с доп. настройками по-умолчанию невидим, автоформатирование подгонит размер диалога под видимый фрейм с основными настройками. Далее онклик с кнопки "more", кидаешь на слот отображения фрейма с дополнительными настройками, и на слот сокрытия кнопки "more". Автоформатирование растянет диалог под ставший видимым фрейм. Далее на фрейме с доп. настройками кнопка "hide", сигналы которой слинкованы с обраными операциями. Итого функционал есть, а писать ничего не надо. Вот как то так эта фича работает в Qt.

Да, когда уже в Делфи запретят кидать на форму невизуальные компоненты? Это помогло бы разделению логики и представления. Плюс не засоряло бы форму. Я-то этого не делаю, но уж больно много быдлокодеров делает.

Цитата korvin @ 27.03.12, 14:45

Или что?

Контейнер. Ну в принципе ладно, будем считать что убедил

Цитата Повстанець @ 27.03.12, 14:52

пару рюшечек для автоформатирования (забыл как называются)

Layout manager?

Цитата korvin @ 27.03.12, 14:53

Да, когда уже в Делфи запретят кидать на форму невизуальные компоненты?

По-моему, ты только что сгенерировал взаимоисключающий параграф, или по-твоему твоя модель должна быть визуальным компонентом? Или может контроллеры должны быть визуальными?