If you look at the C++ devkit examples (or for that matter the explanation
up in the Public Types section for
MNodeMessage<http://download.autodesk.com/us/maya/2010help/API/class_m_node_message.html>)
you can see the problem. Namely, the enum values correspond to hexadecimal
numbers. If you run hex() on the number, you will see what's going on:
hex(18433) is 0x4801, which means:
- kOtherPlugSet (0x4000)
- kIncomingDirection(0x800)
- kConnectionMade(0x01)
I'm guessing the reason for this paradigm is so you are not sending a
separate message for each of these events—otherwise you would have two or
three messages sent for each attribute. As you can see in the C++ examples
(e.g. nodeMessageCmd.cpp), a simple if-statement does not suffice—you must
instead use the bitwise operator:
if ( msg & MNodeMessage::kConnectionMade ) {
cout << "Connection made ";
} else if ( msg & MNodeMessage::kConnectionBroken ) {
cout << "Connection broken ";
} else {
return;
}
Thus, the same goes for Python:
if messageId & OM.MNodeMessage.kConnectionMade:
# Do cool stuff
If a particular message code is not included, the if-statement will return 0
(false). If it is included, it will return decimal representation of the hex
number for that enum, and thus pass the test.
On Tue, Jan 19, 2010 at 2:59 PM, Judah Baron <[email protected]> wrote:
> We're using some of the MMessage classes to register callbacks. For
> MNodeMessage callbacks, the first argument passed in by Maya is the
> messageID. If we check to see if the messageID ==
> OpenMaya.MNodeMessage.kConnectionMade it's always false because the value of
> OpenMaya.MNodeMessage.kConnectionMade is 1. The actual messageID coming in
> to the callback is 18433. The other MMessage related IDs are also not what I
> expected.
>
> Prior to 2008 I didn't have this problem. But prior to 2008 there were
> other issues. As I recall, the MMessage family of classes were not fully
> implemented back then. They seem to be fully implemented now, in that they
> can actually be used, but associating the IDs is a little strange,
> especially when working with multiple versions of Maya.
>
>
>
> On Tue, Jan 19, 2010 at 10:42 AM, Adam Mechtley
> <[email protected]>wrote:
>
>> Could you elaborate a little or provide a specific example? In general, I
>> have not had problems using enumerated types—certainly not where the values
>> are incorrect. An enum in the C++ class simply corresponds to an integer
>> value as far as Python is concerned, so corresponding zero-based integers
>> can be used interchangeably where an enum is required. There are, as always,
>> some exceptions, including a couple of bugs I am aware of:
>>
>> - MTransformationMatrix.getRotation Error (when using a rotation order
>> enum)
>> - api enums passed as reference
>> - Python cannot accept pointer to integer as reference to enum type
>> (need to use short instead)
>>
>>
>> On Tue, Jan 19, 2010 at 12:21 PM, Judah Baron <[email protected]> wrote:
>>
>>> Has anyone experienced problems using Maya's enum values?
>>>
>>> We have had to use integer values directly because the enum values we get
>>> through the class is not correct. It appears to me that the enums coming
>>> through the python class are all zero based and 'localized' to the
>>> assocaited class, whereas maya's enums are generally a lot larger and seem
>>> to be coming from a larger 'global' list of unique values.
>>>
>>> thanks,
>>> -Judah
>>>
>>>
>>>
>>> --
>>> http://groups.google.com/group/python_inside_maya
>>>
>>
>>
>> --
>> http://groups.google.com/group/python_inside_maya
>>
>
>
> --
> http://groups.google.com/group/python_inside_maya
>
--
http://groups.google.com/group/python_inside_maya
