Well, like it says in the docs, they are not guaranteed to work if they are
not initialized first. Follow the pattern you saw in their examples:

 import maya.OpenMaya as openMaya

sel=openMaya.MSelectionList()

openMaya.MGlobal().getActiveSelectionList(sel)

path=openMaya.MDagPath()

obj=openMaya.MObject()

sel.getDagPath(0, path, obj)

compItr = openMaya.MItSurfaceCV(path, obj)

while not compItr.isDone():

u = openMaya.MScriptUtil()

v = openMaya.MScriptUtil()

u.createFromInt(50)

v.createFromInt(50)

uPtr = u.asIntPtr()

vPtr = v.asIntPtr()

compItr.getIndex(uPtr, vPtr)

uVal = openMaya.MScriptUtil.getInt(uPtr)

vVal = openMaya.MScriptUtil.getInt(vPtr)

print '(%i, %i)'%(uVal, vVal)

compItr.next()


On Thu, May 13, 2010 at 4:59 PM, Brandon Harris <[email protected]>wrote:

> I'm going to go out on a limb and say that MScriptUtil is the not
> greatest thing in history of Maya.
>
> here is an example in 2011
>
> select -r nurbsSphere1.cv[4][0] ;
> import maya.OpenMaya as openMaya
> sel=openMaya.MSelectionList()
> openMaya.MGlobal().getActiveSelectionList(sel)
> path=openMaya.MDagPath()
> obj=openMaya.MObject()
> sel.getDagPath(0, path, obj)
> compItr = openMaya.MItSurfaceCV(path, obj)
> while not compItr.isDone():
>    u = openMaya.MScriptUtil()
>    v = openMaya.MScriptUtil()
>    compItr.getIndex(u.asIntPtr(), v.asIntPtr())
>    print openMaya.MScriptUtil().getInt(u.asIntPtr())
>    print openMaya.MScriptUtil().getInt(v.asIntPtr())
>    compItr.next()
>
> 123221088
> 123112400
>
>
>
> I'm really liking these values it kicks back out.
> Maybe some weird maya bug?
>
>
>
>
>
> On May 13, 4:55 pm, Adam Mechtley <[email protected]> wrote:
> > To clarify: the change is only in the docs, not in the behavior. As far
> as I
> > know it is how they've always worked.
> >
> > The example works for me in both 8.5 and 2011 on OSX, so I assume it also
> > works for everything in between. Because this is not the recommended
> usage,
> > however, this may be one of those cases where it's not guaranteed to work
> > unless you first initialize with the proper type of value and then create
> a
> > separate pointer object.
> >
> > On Thu, May 13, 2010 at 4:50 PM, Brandon Harris <[email protected]
> >wrote:
> >
> > > Is this change mainly for 2011? Because if I run the example that I
> > > put up in 2009-x64 on linux, here is what I get.
> >
> > > select -r nurbsSphere1.cv[4][7] ;
> > > import maya.OpenMaya as openMaya
> > > sel=openMaya.MSelectionList()
> > > openMaya.MGlobal().getActiveSelectionList(sel)
> > > path=openMaya.MDagPath()
> > > obj=openMaya.MObject()
> > > sel.getDagPath(0, path, obj)
> > > compItr = openMaya.MItSurfaceCV(path, obj)
> > > while not compItr.isDone():
> > >    u = openMaya.MScriptUtil()
> > >    v = openMaya.MScriptUtil()
> > >    compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > >     print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > >    print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > >    compItr.next()
> >
> > > 0
> > > 0
> >
> > > what I'm going for is for this tool to function across all versions of
> > > maya. I can account for depreciations and such without any issue, but
> > > if they changed MScriptUtil and then didn't document it (as in made it
> > > more strict, or whatever in 2011) Kind of a crappy move.
> >
> > > On May 13, 4:42 pm, Adam Mechtley <[email protected]> wrote:
> > > > Your first example works perfectly fine for me. Here's an example of
> my
> > > > script editor history:
> >
> > > >  cmds.sphere()
> >
> > > > # Result: [u'nurbsSphere1', u'makeNurbSphere1'] #
> >
> > > > select -r nurbsSphere1.cv[3][7] ;
> >
> > > > import maya.OpenMaya as openMaya
> >
> > > > sel=openMaya.MSelectionList()
> >
> > > > openMaya.MGlobal().getActiveSelectionList(sel)
> >
> > > > path=openMaya.MDagPath()
> >
> > > > obj=openMaya.MObject()
> >
> > > > sel.getDagPath(0, path, obj)
> >
> > > > compItr = openMaya.MItSurfaceCV(path, obj)
> >
> > > > while not compItr.isDone():
> >
> > > > u = openMaya.MScriptUtil()
> >
> > > > v = openMaya.MScriptUtil()
> >
> > > > compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> >
> > > > uVal = openMaya.MScriptUtil.getInt(u.asIntPtr()) # note: getInt is a
> > > static
> > > > function, you don't need an instance
> >
> > > > vVal = openMaya.MScriptUtil.getInt(v.asIntPtr())
> >
> > > > print '(%i, %i)'%(uVal, vVal)
> >
> > > > compItr.next()
> >
> > > > (3, 7)
> >
> > > > The reason why your second example doesn't work is because of the
> > > > distinction between initial and working values on MScriptUtil
> objects.
> > > > Calling createFromInt sets an initial value, while passing
> u.asIntPtr()
> > > to
> > > > your function only operates on a working value. Changing working
> values
> > > will
> > > > not change initial values. In the first example, you had no initial
> > > value,
> > > > so it was returning the first working value it found, while in the
> second
> > > > example it returned the initial value (50).
> >
> > > > A lot of this was clarified (or muddied maybe) in the 2011 docs:
> > >http://download.autodesk.com/us/maya/2011help/API/class_m_script_util.
> ..
> >
> > > > On Thu, May 13, 2010 at 3:01 PM, Brandon Harris <
> [email protected]
> > > >wrote:
> >
> > > > > ok, so here's a test to show what's going wrong.
> >
> > > > > grab some components on a nurb surface and run this.
> >
> > > > > import maya.OpenMaya as openMaya
> > > > > sel=openMaya.MSelectionList()
> > > > > openMaya.MGlobal().getActiveSelectionList(sel)
> > > > > path=openMaya.MDagPath()
> > > > > obj=openMaya.MObject()
> > > > > sel.getDagPath(0, path, obj)
> > > > > compItr = openMaya.MItSurfaceCV(path, obj)
> > > > > while not compItr.isDone():
> > > > >    u = openMaya.MScriptUtil()
> > > > >     v = openMaya.MScriptUtil()
> > > > >     compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > > > >     print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > > > >    print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > > > >    compItr.next()
> >
> > > > > Now the issue I have is that it doesn't print the correct values.
> >
> > > > > import maya.OpenMaya as openMaya
> > > > > sel=openMaya.MSelectionList()
> > > > > openMaya.MGlobal().getActiveSelectionList(sel)
> > > > > path=openMaya.MDagPath()
> > > > > obj=openMaya.MObject()
> > > > > sel.getDagPath(0, path, obj)
> > > > > compItr = openMaya.MItSurfaceCV(path, obj)
> > > > > while not compItr.isDone():
> > > > >    u = openMaya.MScriptUtil()
> > > > >     v = openMaya.MScriptUtil()
> > > > >    u.createFromInt(50)
> > > > >    v.createFromInt(50)
> > > > >     compItr.getIndex(u.asIntPtr(), v.asIntPtr())
> > > > >     print openMaya.MScriptUtil().getInt(u.asIntPtr())
> > > > >    print openMaya.MScriptUtil().getInt(v.asIntPtr())
> > > > >    compItr.next()
> >
> > > > > This will just print 50. So how am I plugging this into
> > > > > compItr.getIndex wrong?
> >
> > > > > Brandon L. Harris
> >
> > > > > On May 13, 2:55 pm, Adam Mechtley <[email protected]> wrote:
> > > > > > An MScriptUtil object shouldn't care, since it is a Python
> object.
> > > What
> > > > > > matters is what you tell SWIG it is, not how you construct it in
> > > Python.
> > > > > If
> > > > > > the API wants a reference to a double, but you pass a float ptr,
> it
> > > won't
> > > > > > like it. You'll notice, for instance, that there's only
> > > createFromInt():
> > > > > > there is no createFromShort(), createFromLong(),
> createFromUInt(),
> > > etc.
> > > > > > because they're all the same as far as Python is concerned.
> Likewise,
> > > > > > MScriptUtil.getInt(), MScriptUtil.getShort(),
> MScriptUtil.getBool(),
> > > etc.
> > > > > > all return an int, because Python doesn't discriminate. It really
> > > doesn't
> > > > > > even bother Python if you create from a decimal and request it as
> an
> > > > > int—it
> > > > > > will handle the conversion. For instance:
> >
> > > > > > u = om.MScriptUtil()
> > > > > > u.createFromInt(5)
> > > > > > om.MScriptUtil.getInt(u.asIntPtr()) # this will return 5
> > > > > > om.MScriptUtil.getDouble(u.asDoublePtr()) # this will return 5.0
> > > > > > om.MScriptUtil.getDouble(u.asIntPtr()) # this will not work,
> since
> > > > > > MScriptUtil.getDouble requires an argument of type double &,
> while
> > > > > > u.asIntPtr() is of type int &
> >
> > > > > > On Thu, May 13, 2010 at 1:49 PM, Brandon Harris <
> > > [email protected]
> > > > > >wrote:
> >
> > > > > > > But that also brings me back to the initial scripts.
> >
> > > > > > > u=om.MScriptUtil()
> > > > > > > u.createFromInt(0)#correct usage?
> > > > > > > v=om.MScriptUtil()
> > > > > > > v.createFromInt(0)#correct usage?
> > > > > > > compItr.getIndex(u.asIntPtr(),v.asIntPtr())
> > > > > > > om.MScriptUtil.getInt(u.asIntPtr())
> >
> > > > > > > OK so if I use createFromInt and just feed it an arbitrary
> value to
> > > > > > > allocate the space, is that correct? what do I have to consider
> > > when
> > > > > > > doing that? if the number may have a value like 20 instead of
> 2, do
> > > I
> > > > > > > need to do createFromInt(100) or something to give it adequate
> > > space?
> >
> > > > > > > Brandon L. Harris
> >
> > > > > > > On May 13, 1:36 pm, Brandon Harris <[email protected]>
> wrote:
> > > > > > > > OK so when I do this
> >
> > > > > > > > u=om.MScriptUtil()
> > > > > > > > u.createFromInt(0)
> >
> > > > > > > > the u.asInt is equal to 0.
> >
> > > > > > > > so when I do that I need to do
> >
> > > > > > > > u.createFromInt(Value That Will Be Used)
> >
> > > > > > > > On May 13, 1:28 pm, Adam Mechtley <[email protected]>
> > > wrote:
> >
> > > > > > > > > Basically:
> >
> > > > > > > > > Imagined through the lens of a language like C++, Python
> always
> > > > > passes
> > > > > > > > > simple types (integer, decimal, etc.) by value—you are
> passing
> > > > > actual
> > > > > > > > > numeric data. Some places in the API, however, require that
> > > simple
> > > > > > > types be
> > > > > > > > > passed by reference (that is, passing an address to some
> > > numeric
> > > > > data
> > > > > > > rather
> > > > > > > > > than passing the numeric data itself). In such cases, there
> is
> > > no
> > > > > > > automatic
> > > > > > > > > way for the SWIG layer to translate a simple type into a
> > > > > *reference* to
> > > > > > > a
> > > > > > > > > simple type. An MScriptUtil object is thus basically a way
> of
> > > > > wrapping
> > > > > > > a
> > > > > > > > > simple numeric value (like an integer or decimal) in a
> complex
> > > > > object
> > > > > > > so it
> > > > > > > > > can be passed by reference.
> >
> > > > > > > > > In your example, u is an object containing a simple integer
> > > value
> > > > > (0 or
> > > > > > > 20
> > > > > > > > > or whatever you give it when you construct it). The sole
> > > function
> > > > > of u
> > > > > > > is
> > > > > > > > > thus to pass its contents by reference (u.asIntPtr()) or to
> > > obtain
> > > > > the
> > > > > > > value
> > > > > > > > > when something else has changed it (u.asInt()).
> >
> > > > > > > > > On Thu, May 13, 2010 at 1:11 PM, Brandon Harris <
> > > > > [email protected]
> > > > > > > >wrote:
> >
> > > > > > > > > > OK, I believe that by changing some of this I have
> actually
> > > > > crippled
> > > > > > > > > > some functionality. So is there more information on
> exactly
> > > what
> > > > > > > > > > u=om.MScriptUtil()
> > > > > > > > > > u.createFromInt(0)
> > > > > > > > > > actually does and if I use 20 instead of 0 what happens?
> > > > > > > > > > Forgive my ignorance. Just an odd class that I'm not sure
> on
> > > what
> > > > > > > it's
> > > > > > > > > > doing so not 100% on how I'm to use it properly
> >
> > > > > > > > > > On May 11, 12:20 pm, Brandon Harris <
> [email protected]>
> > > > > wrote:
> > > > > > > > > > > Alright. That did seem to be the issue. big thanks for
> the
> > > > > help!
> >
> > > > > > > > > > > Brandon L. Harris
> >
> > > > > > > > > > > On May 11, 10:21 am, Paul Molodowitch <
> [email protected]>
> > > > > wrote:
> >
> > > > > > > > > > > > Yup... the only thing I would add is that you need to
> > > > > allocate
> > > > > > > space
> > > > > > > > > > for
> > > > > > > > > > > > whatever you're going to be storing - the default
> > > constructor
> > > > > > > allocates
> > > > > > > > > > NO
> >
> > ...
> >
> > read more »
>
> --
> http://groups.google.com/group/python_inside_maya
>

-- 
http://groups.google.com/group/python_inside_maya

Reply via email to