Добрый день.

Расскажите, как надо:
Есть форма [1] (допустим, отображение документов), она вызывает немодальную форму [2] конкретного документа (который имеет свои табличные части). При открытии формы [2] должны быть загружены, допустим, 2 датасета (формы и табличной части Товары). При закрытии формы [2] происходит сохранение в форме [1]. При том что из одной формы [1] могут быть открыты несколько форм [2], и форма [1] должна верно обработать оба события от формы [2]. Как верно это реализовывать?

Пробовал через callback-функции. Процедуры загрузки и сохранения должны прописываться в какой из форм? Подозреваю, что в форме [1]. Тогда как передать нужные данные из формы [2]?

Короче, запутался. Не могли бы поделиться опытом? Если с примерами, так вообще замечательно.

A что собственно созраняется?
Вообще есть как минимум четыре механизма решения пост. зад.
1 Делегаты( в дэльфе - указ на методы (события))
2 Механизм виндовых сообщений
3 Callback - функции ( Концептуально, похожи на делегаты).
4 Интерфейсы.
Также для реализации подобных весщей, можно используется vcl-механизм нотификации.
А в-о-о-от какой из механизмов выбрать, зависит от других факторов (в том числе и от заданного вопроса), например межобъектная/межмодульная связность!

Это сообщение отредактировал(а) cat512 - 13.2.2011, 11:49

При сохранении в дочерней форме сделанные изменения должны быть сохранены в базе данных. Кто должен производить загрузку и сохранение?
а) Главная форма - тогда каким образом передать данные из дочерней формы в главную (при условии что дочерняя форма ничего не должна знать о главной)?
б) Дочерняя форма - тогда на главной форме необходимо сделать обновление данных для получения актуальной информации (можно еще усложнить вариант, когда этот документ отображается еще в одном окне - желательно, чтобы изменения отобразились и в нем) 

Вообще, есть типовый юзер интерфейс, в приложениях для работы с БД - основанный на формах - селекторах (отображают информацию) и  модальных формах - модификаторах (модифиц. данный в бд), который избавляет пользователей от изобретения велосипеда. 
Очевидно ты пошёл своим путём."велосипеда"  
Теперь по сути;
1 Есть сомнение что это вообще надо делать! О каких данных идёт речь? 
2 Это делается очень просто! Используется либо мех. виндовых сообщений(рефрешь по сообщению), либо нотификаций(рефрешь по событию).

Я вроде описал в первом сообщении: допустим, это окно документов и окно конкретного документа. Однако, это одна из ситуаций

Лично мне кажется, что логично закрепить за формой изменяющей данные, ответственность фиксации/отката изменений

Спасибо за ваши ответы.

То есть дочерняя форма должна изменять данные и уведомлять об этом главную форму?
Но есть удобство, когда это делает главная форма. Взять хотя бы ситуацию с добавлением новой записи - если это делает главная форма, не нужно перечитывать весь датасет. Если это делает подчиненная форма - датасет необходимо перечитать полностью.

зы. Вопрос про виндовые сообщения: можно ли как то передать вместе с сообщением какой-то свой пользовательский класс?

Это вопрос целесообразности и накладных расходов. Если дочерняя форма не несёт никакой информативной нагрузки для конечного пользователя, то зачем она тогда вобще нужна!!!
Имеет смысл обойтись одной главной формой. 

Есть некоторые компоненты, которые позволяют делать "точечный рефрешь"

Можно, например так:

Я привел пример про документы. Редактировать документ в таблице? Вы где-нибудь видели это решение?


Есть, но им нужен ключ для рефреша. Вкратце, они делают запрос типа "select * from TABLE where ID = :Key"


Большое спасибо, попробую.

(продолжу на "ты", надеюсь не обидишься)
Ведь ты сам и предложил концепцию редактирования данных через грид  :

Каким образом главная форма (без помощи дочерней), может редактировать данные, как не через грид? Я лишь хотел подчеркнуть тот факт, что при дизайне UI, надо тоже пользоваться принципом "необходимой достаточности". 

Нисколько


Я предлагал редактирование через датасет(ы), лежащий на главной форме. Но никак не грид


Я про грид ни разу и не сказал. На главной форме датасет (или датасеты), она вызывает подчиненную форму, получает каким-то образом оттуда данные и сама производит манипуляцию с ДАТАСЕТОМ (или ДАТАСЕТАМИ). Ни слова о гриде. Он может как быть, так и не быть.

А вот редактирование таких сложных объектов, как документ с табличными частями (Detail-датасеты), в гриде - это уже изврат, ИМХО.

То есть, главная форма "lдокументов" не содержит элементов управления/отображения? И непредпологает интерактивное взаимодействие с пользователем? Интересно как пользователь будет редактировать данные через датасеты, не имея эл. управления/отображения?

А вот здесь, как раз идёт речь о главной форме вне контекста дочерней!



То есть это я предложил редактировать данные через грид??? И что означает выражение "табличная часть"?

.





Это сообщение отредактировал(а) cat512 - 13.2.2011, 11:45

Приведу пример, разных вариантов реализации UI
1 MDI интерфейс - форма селектор (документы) с датасетом и акшенами модификации
.                            - модальная/ые форма/ы модификаторы (для конкретных экз. документов) (имеют метод с параметрами (классовый), через которые передаётся информация для точечного рэфреша
2 Более продвинутый (imho боле правильный) вариант
SDI/ MDI (не важно). Все датасеты(комп. доступа) находятся в датамодуле (imho там им и место)
На формах толькр елементы управления/отображения данных. В датасетах перекрыты методы на модификацию данных, которые будут вызывать МОДАЛЬНЫЕ формы модификаторы. Причём в этом случае мы имеем один датасет, как для selecta, так и для update. Соответственно проблема, шаринга данных
между формами исчезает.


Это сообщение отредактировал(а) cat512 - 13.2.2011, 12:29

Для удобства должна содержать. Если говорить именно о функционале - не обязана. Я могу просто явно передать, допустим, ID нужной записи в дочернюю форму. Его может быть и не будет видно на главной.


Я не понял.


Про грид никто не предлагал. Вы просто первым его упомянули. Но грид здесь явно не причем.


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

1.Ну ты же наверное "внимательно" прочитал, что в описаных вариантах речь идёт о модальных окнах? А значит, открыть два окна на редактирование данных, он физически не сможет.
2 В случае с MDI интерфейсом (SDI - вообще идеальный вариант), НАЗДАРОВЬЕ, пусть открывает хоть 2000 окон - селекторов (не вижу проблемы разделения даннх в ел. управления от одного датасета)только толку от такого количества открытых форм?

В первом варианте говорится, что окна модальные. Второй вариант об этом не упоминает.

Модальные окна - это тупик.


Уже страницу исписал, но опять этот вопрос.

Ну это подразумевалюсь ещё выше по тексту (2 или 3 пост)
Хорошо, я сейчас поправлю, что бы упоминал

А по чему тупик? Покажи плиз.

Добавлено через 10 минут и 19 секунд
И вообще, поясни плиз почему выбрана модель MDI (на сколко я понял) Зачем пользователю 2 открытых одинаковых окна?

Это сообщение отредактировал(а) cat512 - 13.2.2011, 12:26

Не одинаковых. Окна, несущие одинаковую информацию, не должны дублироваться (например, не должно быть открыто двух окон с одинаковым документом). Окна могут быть разными, но доступными одновременно. Не обязательно с целью редактирования, возможно просмотра (возможно для копирования текста с одного окна в другое). Возможно с целью Drag&Drop.
Да, можно открывать окно модально и делать кнопки открытия дополнительных окон, но (приведу фрагмент чужого мнения, с которым я полностью согласен):



Уйти от подобного возможно и в SDI реализации (например, TabbedView, как это реализовано в Rad Studio и Visual Studio), но при использовании модальных окон отпадает геморрой программиста, но работать в такой программе невозможно (хотя, как известно, привыкнуть можно ко всякому)

Ну хорошо, если сильно хочется, извольте, только я не пойму в чём проблема
кто мешает сделать несколько окон - селекторов с разделяемым датасетом???

Почтеннейший, МОДАЛЬНЫЕ ФОРМЫ - предназначены для МОДИФИКАЦИИ данных, НЕ ДЛЯ ПРОСМОТРА!
Конечно, если в таком контексте их использовать, то и коню понятно, что неудобно!
Для просмотра предназначенны обычные формы! Вот фаша форма "lДокументов" должна быть информативной для пользователя, это как раз пример формы для просмотра!

Я вот привел конкретный пример: человек открывает счет-фактуру, но затем решает посмотреть карточку контрагента или договор (абсолютно реальные условия). Итого у нас три окна: документ / договор / контрагент. Открывать карточку контрагента как селектор? Мать моя женщина, меня съедят пользователи в первый же день.

Короче, я понимаю что вместо обсуждения идет спор, и мне это очень не нравится. Используете модальные формы - на здоровье. Я останусь при своем мнении. За ответы, подсказки и беседу очень признателен. Спасибо большое.

Вы думаете я ТЕЛЕПАТ? Думаете я знаю что там у вас за карточка контрагента, как она реализована и что за бока с ней связаны? И вот такие все ваши посты! Сказали А но не договариваете Б. Вообщем дело ваше, никто вас ни в чём не собирается переубеждать. Заблуждайтесь дальше и лепите датасеты на формах вмевто датамодулей, только учтите, когда разрастётся ваш проект до 500000 - 600000 строк кода, вот тогда у вас появятся настоящие проблемы

Суть моего вопроса был: не "Должен ли я открывать окна в модальном режиме?", а "Как передать с одного окна в другое некое сообщение, если они оба не модальны". Однако разговор ушел в другое русло. Но решение я все равно принял, за это огромное спасибо.


Лепил уже на датамодулях. Больше не буду.