Добрый день.
У меня в Document-View программе два view-шника. Обработчики некоторых кнопок тулбара реализованы в одном из них. Когда активен (щелкнут мышкой) второй view-шник, то кнопки становятся недоступны. Как этого избежать?
Заранее спасибо.

Здравствуйте, potap, Вы писали:

P>Добрый день.
P>У меня в Document-View программе два view-шника. Обработчики некоторых кнопок тулбара реализованы в одном из них. Когда активен (щелкнут мышкой) второй view-шник, то кнопки становятся недоступны. Как этого избежать?
P>Заранее спасибо.

Проследить, что происходит с сообщениями (ON_COMMAND и ON_UPDATE_COMMAND) от кнопок тулбара.
Вероятнее всего, что они где-то теряются.

Возможно, потребуется переопределить виртуальный метод OnCmdMsg (в окне главного фрейма), с тем, чтобы не терялись сообщения.

Здравствуйте, potap, Вы писали:

P>Добрый день.
P>У меня в Document-View программе два view-шника. Обработчики некоторых кнопок тулбара реализованы в одном из них. Когда активен (щелкнут мышкой) второй view-шник, то кнопки становятся недоступны. Как этого избежать?
P>Заранее спасибо.
Переставить обработчики в CDocument, а уже из них пусть CDocument сам стучится к нужным CView — тогда будут доступны постоянно. Вне зависимости где фокус ввода (ну или можно как-то хитрее логику переделать уже внутри CDocument если нужно).

Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, potap, Вы писали:

P>>Добрый день.
P>>У меня в Document-View программе два view-шника. Обработчики некоторых кнопок тулбара реализованы в одном из них. Когда активен (щелкнут мышкой) второй view-шник, то кнопки становятся недоступны. Как этого избежать?
P>>Заранее спасибо.

AG>Проследить, что происходит с сообщениями (ON_COMMAND и ON_UPDATE_COMMAND) от кнопок тулбара.
AG>Вероятнее всего, что они где-то теряются.
AG>Возможно, потребуется переопределить виртуальный метод OnCmdMsg (в окне главного фрейма), с тем, чтобы не терялись сообщения.
OnCmdMsg здесь нафиг не нужен. С CView можно и без этих фокусов работать. И ничего не теряется, просто запросы CN_UPDATE_COMMAND_UI, и CN_COMMAND идут к активному CView, а обработчики в другом находятся.

Да, спасибо, так и сделаю


Здравствуйте, Carc, Вы писали:

C>Здравствуйте, potap, Вы писали:

P>>Добрый день.
P>>У меня в Document-View программе два view-шника. Обработчики некоторых кнопок тулбара реализованы в одном из них. Когда активен (щелкнут мышкой) второй view-шник, то кнопки становятся недоступны. Как этого избежать?
P>>Заранее спасибо.
C>Переставить обработчики в CDocument, а уже из них пусть CDocument сам стучится к нужным CView — тогда будут доступны постоянно. Вне зависимости где фокус ввода (ну или можно как-то хитрее логику переделать уже внутри CDocument если нужно).

И всё-таки, можно ли достаточно легко и компактно изменить логику передачи команд на такую:
Если есть обработчик (как это программно узнать?) в заданном вьюшнике, то вызывать этот обработчик. Если нет, то действовать как и раньше — пересылать app, mainframe, document, активному view.
?

Или даже так хочу:
Заданная кнопка обрабатывается ТОЧНО ЭТИМ обработчиком, ЭТОГО вьюшника. Независимо от того, какой вьюшник сейчас активен.
Нельзя?

Здравствуйте, potap, Вы писали:

P>Или даже так хочу:
P>Заданная кнопка обрабатывается ТОЧНО ЭТИМ обработчиком, ЭТОГО вьюшника. Независимо от того, какой вьюшник сейчас активен.
P>Нельзя?

А почему бы не перенести обработчик "заданной кнопки" на класс-наследник CMDIFrameWnd и из обработчика в головном окне фрейма уже отсылать сообщение на требуемый "вьюшник"? Конечно, это потребует больше ручной работы, но именно это, на мой взгляд, вариант для такого случая.

Не очень нравится тем, что приходится реакцию на кнопку иметь в 2х местах: в CMainframe и CMyView. Этих кнопок у меня не мало.
Да и несистемно как-то, помнить об этом вечно надо.
Хочется написать где-то некий локальный код, так чтобы все кнопки, включая будущие, обрабатывались по описанной методе.



Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, potap, Вы писали:

P>>Или даже так хочу:
P>>Заданная кнопка обрабатывается ТОЧНО ЭТИМ обработчиком, ЭТОГО вьюшника. Независимо от того, какой вьюшник сейчас активен.
P>>Нельзя?

AG>А почему бы не перенести обработчик "заданной кнопки" на класс-наследник CMDIFrameWnd и из обработчика в головном окне фрейма уже отсылать сообщение на требуемый "вьюшник"? Конечно, это потребует больше ручной работы, но именно это, на мой взгляд, вариант для такого случая.