Detect CTRL + RightMouseButton in SceneHook

C4DS

By default pressing the RightMouseButton in an editor view will show a popup menu. I would want to be able to trigger something similar, but without removing the possibility to trigger the default popup menu with RMB.
For this reason I came up with the combination of CTRL + RMB, which I detect in my SceneHook::MouseInput (as follows):

if (msg.GetInt32(BFM_INPUT_CHANNEL) == BFM_INPUT_MOUSERIGHT)
{
	BaseContainer keyChannels;
	if (GetInputEvent(BFM_INPUT_KEYBOARD, keyChannels))
	{
		Bool ctrlModifier = (keyChannels.GetInt32(BFM_INPUT_QUALIFIER) & QCTRL) != 0;
		if (ctrlModifier)
		{
			ApplicationOutput("SceneHook - MouseInput: RMB + CTRL was pressed");
			return true;
		}
	}
}

This is working fine when a move, rotate, scale tool is active. Even when an own custom created DescriptionTool plugin is active.

However, when the Live Selection tool is active, the code is not triggered.
At least not with the default "EXECUTIONPRIORITY_INITIAL" (=value 1000) I had provided when registering my scenehook plugin.
When I provide "EXECUTIONPRIORITY_ANIMATION (=value 2000) only then does the code get triggered, also when Live Selection tool is active.

return RegisterSceneHookPlugin(MY_SCENEHOOK_PLUGIN_ID, GeLoadString(IDS_MY_SCENEHOOK), 0, MySceneHook::Alloc, EXECUTIONPRIORITY_ANIMATION, 0);

Any value below 2000 just ignores to trigger the code when Live Selection tool is active.
Now, I can understand this is probably not a bug, but made on purpose. But why?
Why would the Live Selection tool have more "priority" then any other tool?

Note:
I am prototyping this with R20 (on Windows). Have not yet tested with later versions. Nor tried on macOS.

Manuel

Hi,

this seems to be a side effect of another bug fix a long time ago that have nothing to do with priorities. In fact, scenehook with a priority lower than 2000 will not be called if you are using another tool than move, scale or rotation.

I asked the devs what they think about it.

Cheers,
Manuel

C4DS

@m_magalhaes said in Detect CTRL + RightMouseButton in SceneHook:

In fact, scenehook with a priority lower than 2000 will not be called if you are using another tool than move, scale or rotation.

That might be the case for ToolData derived tools, but I can confirm that with a DescriptionToolData derived tool active the scenehook (with priority 1000) does get called.

Manuel

There are probably other conditions, for example if popup is not allowed for the tool.
I just wanted to say that it is not a priority issue, but a kind of a bug.

This priority parameter is just for the draw function. If you want to change the execution priority you must use AddToExecution .

Cheers,
Manuel

C4DS

@m_magalhaes said in Detect CTRL + RightMouseButton in SceneHook:

popup is not allowed for the tool

I didn't think of that one.
This does seems to mean that using SceneHook::MouseInput to detect CTRL+RMB is probably not the right approach.

Is there another way to detect this action, no matter what tool is active?

Manuel

Sorry for the late reply, it will take a bit of time to fix this issue. Things must be changed carefully in that part of the code. I do not think there is a better way of checking the right click but I am quite sure there are some cases where the event will be consumed and you will not know it.

Cheers,
Manuel

C4DS

No worries.
From your reply it seems this is a bug that is being tackled in a future release.
I don't mind this being fixed, but was hoping for another solution (or workaround) to be available for current and older versions (I am still on R20).

However, if using the MouseInput is the only way to go for detectig CTRL+RMB (with known limitations) then I guess we can close this topic.
Thank you for your time.

Manuel

The workaround is to have your scenehook priority over 2k. Remember this priority is reversed, the lowest, the latest to be called so you can delete what have been done by other scenehook. (if you are using the draw function)
The function will call scenehook beginning at LIMIT<Int32>::MAX to 2000 included.

This bug was introduced more than 10 years ago after fixing another issue. The code is old and would need a session of refactoring.

Cheers,
Manuel