C++ SDK: I want to receive notifications when a dialog is opened.

[琥珀 猫太郎]

I want to receive notifications when a dialog box opens. Is that possible?

[Manan Joshi]

Hi @琥珀 猫太郎,

If it is your own dialog then DialogController could help which you must have figured out. If it is some other plugin's dialog look for a possibility of adding your observer to it. Another option not tried by me could be to look into suppressedUI

-Manan

[琥珀 猫太郎]

I'm hoping to catch when the shortcut dialog opens.
I have absolutely no idea what to add the Observer to.

[Dirk Becker]

It usually opens when the action is invoked …

There is some weird way so action components can watch other actions, even without overriding them.

Read the headers on those special fields and constants in action definition resources.

Scripted action events should work the same way, or they may be easier if you work both sides.

[Dirk Becker]

When you prefer observers, attach to kAppBoss kWindowAddedMessage IID_IWINDOWLIST.

The void* is a kMovableModalWindowBoss, next level is kKBSCEditorDlgBoss .

On the way out that's kRemoveWindowMessage

[琥珀 猫太郎]

Thank you for the valuable information.
I was trying to see if it could be done using idleTask.
I was modifying the RunTask method in PnlTrvIdleTask.cpp of the SDK's PanelTreeView and testing it.

if( appFlags == IIdleTaskMgr::kModalDialogUp)
{
	do
	{
		InterfacePtr<IApplication> iApplication(::GetExecutionContextSession()->QueryApplication());
		if (iApplication == nil) break;

		InterfacePtr<IDialogMgr> iDialogMgr(iApplication, ::UseDefaultIID());
		if (iDialogMgr == nil) break;

		IWindow* iWindow = iDialogMgr->GetFrontmostDialogWindow();
		if (iWindow == nil) break;

		InterfacePtr<IDialog> iDialog(iWindow, ::UseDefaultIID());
		if (iDialog == nil) break;

		iDialog->PressDefaultButton();

	} while (false);
}

I succeeded in closing the dialog after it opened.

Regarding the kAppBoss kWindowAddedMessage IID_IWINDOWLIST you suggested,
I'll give it a try. Thank you for your kindness.

[Dirk Becker]

When you really intend to suppress or replace the dialog, it might be sufficient to remove the action using an action filter. On the other hand, that's also a drastic step towards users so think twice.

@Manan Joshi also mentioned the SuppressedUI plugin template, it might also do what you want. I never liked the idea so I don't know its details, e.g. if you borrow some code from there would you be able to coexist with other plugins that do the same?

[Manan Joshi]

@Dirk Becker adding to the topics of observers. I was thinking of adding an observer to an existing dialog or panel. So lets say we have a situation where we want to do this and using the IID_IOBSERVER is not feasible as it is already used. So what are the options for us to call the autoAttach and autoDetach method. We can add our new implementation on a custom IID to the dialog boss but how to hook up the observer using autoAttach and autoDetach? Is there a safe pattern to achieve this?

Even for non UI classes lets say we try to add an observer to kAppBoss and if it already has an implemented IID_IOBSERVER then how to do we proceed? In my opinion it is best to not use the IID_IOBSERVER as you never know some other plugin tries to implement it again and our implementation is overridden

-Manan

[Dirk Becker]

Fully agree – such implementations (not just observer) at their default IID should get added only to your own boss classes. Otherwise you risk collisions with other plugins, or later versions from Adobe, that attempt the same trick.

You'd AutoAttach/Detach them from any code that comes along, mostly all those notifications. I'd also avoid to interfere with existing UI, e.g. close a dialog just opened by the user. From an idle task, ugh. There are other mechanisms for that, several mentioned here.

[Manan Joshi]

Ok, so the actual problem statement then would be to identify and tap the correct notification if present. If there is no notification for certain case then more or less we are stuck. I was thinking more on the lines of being self sufficient and not relying on external triggers. Like when the boss class is generated, the constructor of our custom observer implementation would be called as well I suppose. But, calling AutoAttach from constructor and AutoDetach from destructor would not be safe/recommended I suppose. Some similar idea that may work?

-Manan

[琥珀 猫太郎]

I tried it.

InterfacePtr<ISubject> iSubject(iApplication, ::UseDefaultIID());

iSubject->AttachObserver(
    ISubject::kRegularAttachment, this, IID_IWINDOWLIST, IID_MYOBSERVER);

In Update method

if (theChange == kWindowAddedMessage) {
	// 
}

I was able to catch the message that opens the dialog.

How do I use kMovableModalWindowBoss
and kKBSCEditorDlgBoss?

Also, I want to manipulate the opened dialog.
When using IIdleTask, I could manipulate the opened dialog, such as pressing buttons.

After catching the dialog open message with an observer, is it possible to then manipulate the dialog?

It seems like the program might be executing before the dialog finishes opening.

[Dirk Becker]

So you're still looking at shortcuts and related UI. This summer I also spent some (too much) time on them, as an exercise in UXP, initially copied the existing dialog to validate my script methods. Below is the intermediate result with a few additions. One time sink was to convert between UXP key events and virtual keys, also capture all of them. Better done in C++, UXP is far from complete. I filed several related improvement suggestions.

On the other hand have a look at Bridge or Premiere and see their reworked KBSC Editor, I guess that at some point in time this will also trickle down to InDesign rendering outside efforts obsolete, so I shifted back my focus to other projects.