Another way to get the cameras for the camera projections on the selected object. This time with no loops (well, except for the list comprehension on line 22).
from siutils import si
if Application.Version().split('.')[0]>= "11":
si = si() # win32com.client.Dispatch('XSI.Application')
from siutils import log # LogMessage
from siutils import disp # win32com.client.Dispatch
from siutils import C # win32com.client.constants
# Get all CameraTxt operators
ops = si.FindObjects2( C.siOperatorID ).Filter( "CameraTxt" )
# Filter function to get the CameraTxt ops under the selected object
def f(x):
o = si.Selection(0)
return o.IsEqualTo( x.Parent3DObject )
# Get list of cameras
cams = [ x.InputPorts(2).Target2.Parent3DObject for x in filter( f, ops ) ]
if len(cams) > 0:
print 'Projection cameras for %s:' % si.Selection(0)
for c in cams:
print ' %s' % c.Name
This script is based on the observation that you can get the camera from an input port on the CameraTxt operator.
eX-SI 
I’m confused: why do you include a dispFix in this script? From your earlier post – http://tinyurl.com/xsisupdispatch – I gathered the whole dispatch problem was more or less dealt with (around XSI 6)…
P.S. Your direct link to the previous entry doesn’t seem to work…
There is a http:// stuck at the end of the URL
Thanks, I fixed the link.
dispFix is still needed sometimes…but as it turns out, not in this case…Thanks!
I had stuck it in an earlier version of the script when something wasn’t working, and then just carried it forward.
I am afraid I am going to have to beg you for a new post on this dispatch issue. In what kind of cases is a dispFix still needed?
I don’t know really. But sometimes you find some method or property doesn’t work on an object, so you try dispFix(). Search this site, there’s two examples. One is the ViewportCapture object.
Okay, I’ll try to live with the uncertainty… 😀
But wouldn’t that mean the classic fix (the “__init__.py file hack”) still is the best option as it should eliminate the problem once for all? Or is this not true either?
I’ve never tried the classic __init__.py hack.
I suppose if I kept running into more and more problem areas, then I might try it.
But so far I’ve hit only three cases, and iirc two of them were kind of ‘corner cases’ like the ViewportCapture object, which is hard to get at if you don’t use Dictionary.GetObject.
But if the problem still exists and Softimage does have its own “internal” Python now and even if only a few occasions are still problematic, wouldn’t it still be an idea to incorporate the __init__.py hack in future basic internal Python installations?