PLM-forum.ru

CATDlgNotify диалог приостанавливает выполнение процесса и ожидает реакции от пользователя.

К примеру , в BuildGraph команды есть :

Код: Выделить всё

CATDlgNotify pNotif = new CATDlgNotify(...);
int Ret = pNotif->DisplayBlocked(...);

if (nRet == 4)
{
     RequestDelayedDestruction();
      return;
 }

CATDlgDialog * pMyDlg = new CATDlgDialog ();
pMyDlg -> Build();
pMyDlg ->SetVisibility(CATDlgShow);

Диалог pMyDlg появиться на экране только после того как отработает CATDlgNotify диалог, а не одновременно .

Как создать свой диалог, отнаследованный от CATDlgDialog , с таким же поведением как у CATDlgNotify диалога ?

Привет,

Уточни плз. суть вопроса:

Нужно чтобы CATDlgNotify появлялся после (одновременно с) отображением "родительского" диалога,
или нужен не модальный (не блокирующий рабочий поток / "родительское окно") аналог CATDlgNotify.

И то, и то возможно... способы реализации кардинально отличаются

booSter писал(а):Привет,

Уточни плз. суть вопроса:

Нужно чтобы CATDlgNotify появлялся после (одновременно с) отображением "родительского" диалога,
или нужен не модальный (не блокирующий рабочий поток / "родительское окно") аналог CATDlgNotify.

И то, и то возможно... способы реализации кардинально отличаются

Нужно чтобы родительское окно с диалогом появлялось только после того , как закончена работа с диалогом "аля CATDlgNotify" . К примеру , запускаем команду "Купить_3_батона" , у которой есть свой диалог Выбрать_Тип_Батона_Dlg. В BuildGraph комманды есть проверка на наличие денег, и если их недостаточно,то нужно вывести диалог Дайте_денег_Плз_Dlg . В этом "аля CATDlgNotify" Дайте_денег_Плз_Dlg диалоге можно ввести дарителя и сумму. И только по кнопочке "Завершить дарение" продолжить комманду "Купить_3_батона" с того же места, где была прервана диалогом Дайте_денег_Плз_Dlg , и запустить диалог Выбрать_Тип_Батона_Dlg.
Комманд типа "Купить_3_батона" около 7 , вводить новые состояния (state) и анализировать переходы не сильно хочеться по причине загромождения кода. Есть ли альтернатива ?
GUR

По-хорошему всю "прелюдию" с проверкой/запросом "денег" нужно производить в рамках стэйт-машины <state-chart>. Другие альтернативы то-же возможны, но выпадают из идеологии.

А для того чтобы минимизировать правки в коде (7+ вариантов "покупки_батонов") - я бы вынес логику "прелюдии" в базовый класс "Купить_Cmd". Таким образом цепочка наследования для класса "Купить_3_батона" (и для остальных) станет такой:

Код: Выделить всё

CATStateCommand
  +--<--"Купить_Cmd"
          +--<--"Купить_3_батона"                   


В классе "Купить_Cmd" нужно определить BuildGraph так, чтобы он строил стэйт-чарт прелюдии и производил связянную с ним инициализацию.
А в методе "Купить_3_батона"::BuildGraph (и в остальных 7+ вариантах) нужно в соответствующем месте добавить вызов "Купить_Cmd"::BuildGraph(), а так же проверить чтобы вместо "InitialState" использовался конечный стэйт "прелюдии"

На первый взгляд выглядит жутковато , НО
даёт решение полностью соответствующее идеологии стэйт-чарт машины с минимальными правками кода