Forcing dynamic dispatching in Python’’s win32com

May 12th, 2005 by Patrick Boucher - Viewed 6532 times - Popularity: 9%




I’ve gotten a few e-mails of people trying out my PB_Jitter plug-in and getting the following error:

[...snipped by editor...]
”AttributeError: ”” object has no attribute ”OriginPath”
[...more bla bla bla...]

This is due to XSI returning an object with an incorrectly set multi-dispatch interface. Unfortunately in this instance the dispFix function in buzz.xsi doesn’t seem to get the job done and the only way I’ve been able to fix it is by changing a python file. By changing this python file XSI will always give you dynamically dispatched objects and you won’t even need the dispFix function… ever again.

  1. Find the file called %PYTHONPATH%\Lib\site-packages\win32com\client\__init__.py.
  2. Edit the function called __WrapDispatch.
  3. Comment all the lines inside this function except the last one that starts with return.

I do this almost systematically on every system I install Python for primary use inside XSI.

Thanks to Jerry Gamache who posted these solutions (dispFix and permanent solution) on the XSI mailing list in the first place!

7 Responses to “Forcing dynamic dispatching in Python’’s win32com”

  1. brad Says:

    Hey, this seems to help to a certain extent, but I now periodically get the following error:

    ”ERROR : Traceback (most recent call last):
    ” File “”, line 2, in ?
    ” import buzz.cg.noise as noise
    ” File “C:\Python23\Lib\buzz\cg\__init__.py”, line 1, in ?
    ” from file import *
    ”ImportError: No module named file
    ” - [line 2 in C:\Softimage\XSI_4.2\Application\Plugins\PB_JitterOp.py]
    ”ERROR : 2000 - Error loading script file: ”C:\Softimage\XSI_4.2\Application\Plugins\PB_JitterOp.py”. Operator ”cube.cube.PB_JitterOp” will no longer be evaluated.
    ”Debugging interfaces not available - debugging is disabled..

    Is this a related problem?

  2. Patrick Boucher Says:

    At first glance it seems to be the operator is not finding the buzz library.

    You need to install the buzz library from a few posts back. That means putting it somewhere on your drive and adjusting your PYTHONPATH environment variable to include the path where you uncompressed the library. You can alternatively uncompress the library in C:\Pythonxx\Lib\site-packages.

    To see if python and the buzz library are properly installed you can just run the following few lines in the script editor (python language of course):

    from buzz.xsi import *
    import buzz.cg.noise as noise
    log(noise.noise(15))

    should output:

    #INFO : 0.718757729046

  3. Patrick Boucher Says:

    Wait… I think I forgot a file when I packaged the library… Doh! Try redownloading it!
    Sorry about that!

  4. brad Says:

    Everything works great now, thank you!

  5. biju Says:

    Any idea why I get the following error - i guess its not able to find siMenuTbAnimateCreateParameterID

    #ERROR : Traceback (innermost last):
    # File “”, line 18, in XSILoadPlugin
    # in_reg.RegisterMenu(c.siMenuTbAnimateCreateParameterID, “PB_JitterMenu”, False)
    # File “C:\Python22\Lib\site-packages\win32com\client\__init__.py”, line 131, in __getattr__
    # raise AttributeError, a
    #AttributeError: siMenuTbAnimateCreateParameterID
    # - [line 130]
    #ERROR : 2262 - This plug-in could not be loaded:
    #
    #

    Thanks

    Biju

  6. Patrick Boucher Says:

    I have seen this and to be quite honest, I”m not absolutely certain where it comes from. What is obvious is that it’’s having a hard time with anything that comes from the ”c” variable which is a shortcut to win32com.client’’s constants, i.e. XSI’’s constants.

    I have noticed that on systems where I fresh install Python and XSI, if I force dynamic dispatching in Python (the procedure described in this article) before I start XSI, I will get this error on several of my plug-ins that access XSI/win32com constants. To fix, XSI must be started while the Python module is stock and unmodified. Then, when win32com.client’’s __init__.py file is modified, you have a working Python in XSI with forced dynamic dipatches and accessible constants.

    To recap:
    - Fresh XSI and Python
    - Start XSI, something gets registered in Python or the system, I”m not positive what. Magic happens.
    - Shutdown XSI
    - Modify Python’’s win32com.client __init__.py file
    - Restart XSI and keep your fingers crossed.

    As I said. I”m not certain… well… I don”t know why this happens so metimes. Happened on 3 of the 23 systems I administer: XSI 4.2 / ActivePython 2.4.

    This procedure is just a hack to circumvent the fact that sometimes XSI doesn”t return a properly dispatched object. Hopefully with Python’’s growing popularity in the XSI community and with people like Jerry Gamache and the Softimage crew on the case, Python in XSI will only get better and more stable as versions go on.

  7. Jason Dexter Says:

    Hello Patrick

    I”m still a novice with Python and have been looking over the BuzzLibrary that Buzz and you were kind enough to share. I am having troubles with getting the plugins (Selection for Camera specifically) to work. Could you clarify specifically what you mean by:

    - Modify Python’s win32com.client __init__.py file

    I was looking at the ___init__py file you provided in the latest buzz version, but it has no code in it to refer to.

    Anyway, thanks again.

Leave a Reply