Maya crash, docked WPF plugin stealing input and Python marshalling issues

[jegustin]

Hi!

My name is Jesper Gustin and I'm a Senior Software Engineer at Microsoft.

We have a plugin which uses the OpenMaya .NET interfaces to build a plugin UI in WPF together with a Python/MEL interface. We have multiple issues, see below.

1. The WPF plugin causes input hijacking issues (shortkeys stops working in the viewport) and the very same behavior can be seen when first docking (important, since this only happens after docking it) and interacting with the DAGExplorer example under devkit\dotnet\wpfexamples.

2. The other issue we are seeing is that Python commands that extends MPxCommand and IMPxCommand fails to forward the arguments to doIt() properly when running them through the Python interface exposed on the cmds object directly. I have attached a minimized test case which is basically copy/pasted from the documentation. Results when calling it in different ways:
* cmds.MayaCmdBug(test='myString') -> 0 elements in the MArgList (this is however the one that I expect to work, since this is the expected syntax)

* cmds.MayaCmdBug('test', 'myString') -> 2 elements in the MArgList

* mel.eval("MayaCmdBug -test \"myString\"") -> 2 elements in the MArgList

3. The third issue we are seeing is a crash when the short argument name string for the MPxCommandSyntaxFlag decorator is greater than 4 characters long (also in the attached minimized test case).

[cheng_xi_li]

Hi Jesper,

The short name for a flag should be less than four characters, here is the link.

The first and second issues looks like defects. Let me check it out.

Yours,

Li

[jegustin]

Hi Li,

Thank you for the quick response and for looking into the issues!

Regarding the short name string length, here's the documentation that I've been following: Maya Help | Using .NET assembly attributes | Autodesk. Notice that there is no limitation to string length mentioned anywhere, it just says:

• flag’s short name: The short name for the flag (for example: -i).

And since this is C#, and the argument type is a System.String, it allows me to put in any length into the decorator argument. And since the decorator is evaluated as soon as the plugin is loaded, there is no way to catch what is actually causing the crash and the crash log user output XML does not contain any stack trace or similar useful information. I had to do trial and error until I found what was causing the crash. It would maybe be possible for you to create your own string type which has this limitation built in already (see e.g. https://stackoverflow.com/a/6952723)? That way you would be able to check this during compile time and a crash could be avoided.

Could you please also elaborate on the importance of including the "-" in the argument names? There's at least one example in the SDK zip (devkit/dotnet/examples/conditionTest/conditionTest.cs) that isn't including it. Should it, or should it not be included? And what happens if I forget to include it? I can't find anything about this in the .NET part of the documentation either?

//Best regards, Jeppe

[cheng_xi_li]

Hi Jesper,

The .Net API for Maya is proxy wrapper for C++ API. You can use C++ API as reference. I've logged your suggesion and the rest of problems in our system, please check out your email for the details.

The "-" should be irrelevant. It will be ignored when creating the flag. You can add it or not as your wish.

Yours,
Li