Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Не слишком благодарное дело - тянуть подход из библиотеки с одной идеологией в библиотеку с другой. 22.07.03 08:35 Число просмотров: 1343
Автор: void <Grebnev Valery> Статус: Elderman
|
> Насколько я знаю, в подавляющем большинстве случаев для
> обмена "сообщениями" между элементами интерфейса вполне
> достаточно либо непосредственной посылки оконного (WM_)
> сообщения элементу с заданным именем
Да. Это полезный инструмент. Но не получится.
Я напишу о его использвании отдельным постом.
А просто так SendMessge(....) не удастся использовать. Послать сообщение можно, но, зная хэндл (WinAPI) или указатель (CWnd*) конкретного получателя (например, диалога). Он неизвестен в общем случае, если только не сделан глобальным.
> сообщения элементу с заданным именем, либо паттерна
> publish-subscribe (publish-subscribe, он же Observer,
> вообще часто является краеугольным камнем при построении
> пользовательских интерфейсов). Таким образом можно
> реализовать либо push-доставку информации объекту (WM_),
> либо pull-доставку (Observer). Второй вариант, имхо,
> значительно лучше сразу по ряду причин (если есть желание,
> могу здесь написать подробнее)
Да. Спасибо. Я посмотрел. Хорошие идеи. Немного похоже на то, что я хочу.
Только там гораздо круче.
> Касаемо твоего случая - могу предложить следующее. Для
> FillControls и DisplayControls в MFC есть очень удобный
> метод под названием UpdateData. ....
Да метод есть. Только не поможет это. UpdateData гоняет данные переменной-члена диалога туда-сюда. Т.е. из переменной диалога - в GlgItem объекта CWnd. Надо другое... Необходимо, например, чтобы в зависимости от данных одного диалога изменялись данные другого
объекта MFC, который вообще создан из другого CView, например, состояние CTreeCtrl. Другими словами, диалоги и другие CWnd объекты
должны взаимодействовать, а не контролы.
>.... описываешь, что нужно делать, на уровне формы, а не каждого
> элемента интерфейса.
Наверное, ты меня не понял. Я не собираюсь писать указанные обработчики
для элементов. Идея другая - общий обработчик FiilControls и DisplayControls
для ГРУПП ФОРМ, а не одной формы. Хотя последнее не исключается.
Можно комбинировать.
> Предвижу возражения насчет сконцентрированности кода.
Возражений вообще не может быть с моей стороны, т.к. я предложил
дискуссию, а не свою идею в качестве постулата.
> моем случае операции по изменению свойств элементов
> интерфейса не собраны в одном месте. Но подумай сам: а оно
> тебе надо? Какой выигрыш от этого ты получаешь?
Ты не понял, или я плохо объяснил. Из "одного места" должна управляться общая логика изменения свойств элементов интерфейса.
Посмотри следующий мой пост, плз.. Там я подробнее описываю, что мне надо.
Спасибо за пост.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
