Settings Wheel / Promote Commands for Shortcut

On 18/01/2018 at 07:00, xxxxxxxx wrote:

Hey guys,

I actually have two questions in one post:

1.) How can i add this little settings wheel to my plugin-icon?
https://www.dropbox.com/s/pgv1dt1tlk59590/settings_wheel.png?dl=0

2.) How can I promote Buttons of my Plugin for Shortcut-Functionality / Customize Commands
(For example: "Connect Node to Output" from Redshift, which is a button in the graph editor.)
https://www.dropbox.com/s/846mwki4suhr0oa/promote_commands.png?dl=0

Can anyone help?

Thanks,
Lasse

On 19/01/2018 at 05:05, xxxxxxxx wrote:

Hi Lasse

1. That's just a matter of using PLUGINFLAG_COMMAND_OPTION_DIALOG when registering the CommandData. When the user clicks the small cogwheel, it will end up in CommandData.ExecuteOptionID() in your code.

2. Basically Customize Commands just works with commands (CommandData plugins). I assume the buttons you are talking about are in a GeDialog connected to your CommandData plugin. This way it's not working, you can't define shortcuts for such buttons. Rather the other way around: Register a CommandData plugin for the functionality of every button. Then these will appear in Customize Commands and can be assigned with keyboard shortcuts. And in your GeDialog you use CallCommand() as reaction to user's button presses.

On 19/01/2018 at 11:26, xxxxxxxx wrote:

Thank you Andreas, this is quite helpful!!!

On 30/01/2018 at 05:52, xxxxxxxx wrote:

One question remains... I have some options in my dialog that have to influence my "shortcut" cmd-plugin. What is the best way to approach this? I have a locally stored json file, but due to caching of c4d plugins it gives me no realtime response of this data.
Is it possible to somehow read the gedialog from my main plugin within the other cmd-plugin?

Thanks and Cheers,
Lasse

On 31/01/2018 at 02:03, xxxxxxxx wrote:

Hi Lasse,

I'm not sure, what the caching of C4D plugins and the JSON file have to do with each other.

Anyway, I'd do it the other way round. Have a BaseContainer storing your settings/parameters, depending on your needs as global variable, inside of the document's BaseContainer or in the world BaseContainer. In the later cases you'd store your BaseContainer with your plugin ID.
Then your dialog just sets these parameters and in the following may also call one of the commands. And the commands first read these settings and then execute.

So, not your commands try to access the dialog, but the dialog produces data, which is consumed by the commands.