Two ways to dispatch Application - whats the difference?

[Stefan Kubicek]

It is common practice to dispatch the Application object before using it, but I noticed there are at least two different ways of doing it:


1.)
from win32com.client import dynamic as d
App = d.Dispatch ('XSI.Application')


2.)
from win32com.client import Dispatch
App = Dispatch("XSI.Application").Application


The reason I'm actually asking is that I'm running into a problem with timer events with the latter approach,
and I simply want to understand if there are situations where I still want to use it, or if I should always
go with the first one.

If I use the first one, I can create and change my timer event as documented:

def XSILoadPlugin( in_reg ):
#=== Register events ===
in_reg.RegisterTimerEvent( "ExecutionTimer", 0, 1 ) #Delayed timer with 1ms and zero repetitions
return True

#Later in the code I can get the timer and reset it like so:

oTimer = App.EventInfos( "QMenuExecutionTimer" ) #Find the timer
QMenuTimer.Reset( 0, 1 ) #Reset the timer

This works fine with the first approach described above.

However, if I use the second one and try to reset the timer event, I get:

AttributeError: '<win32com.gen_py.Softimage|XSI Object Model Library v1.5.EventInfo instance at 0x488173640>' object has no attribute 'Reset'

There's lots of other stuff going on in the plugin that works perfectly fine, so I guess this is just an Object Model bug, but why, and what's the difference?

Cheers,

Stefan





--
-------------------------------------------
Stefan Kubicek Co-founder
-------------------------------------------
keyvis digital imagery
Wehrgasse 9 - Grï¿œner Hof
1050 Vienna Austria
Phone: +43/699/12614231
--- www.keyvis.at ste...@keyvis.at ---
-- This email and its attachments are
--confidential and for the recipient only--

[jo benayoun]

Hey Stefan,

COM Components are an attempt from Microsoft in normalizing object interfaces for easier reusability between different platforms.

To allow the usability of those objects in scripting engines, the normalization add a specification which is the addition of an interface called IDispatch and its set of functions.

That's basically what wraps the set of Dispatch functions + the "pythoncom" adapter you find in the pywin32 package.

By calling "win32com.client.Dispatch",  you're using a shortcut to a high level set of functions including "win32com.client.dynamic.Dispatch".

The call to the ".Application" property is a way to be sure that the right "XSIApplication" instance is returned and not an instance of its base class or something else.

This dispatching process is opaque to you when working in the builtin python scripting engine.

Outside, this simple dispatching code should be preferred.

"""

from win32com.client import dynamic

softimage = dynamic.Dispatch("XSI.Application").Application

"""

-- Jo

2012/7/6 Stefan Kubicek <s...@tidbit-images.com>

[Stefan Kubicek]

Thanks Jo, that's what I've understood for the biggest part as well, except:

> This dispatching process is opaque to you when working in the builtin
> python scripting engine.
> Outside, this simple dispatching code should be preferred.
> """
> from win32com.client import dynamic
> softimage = dynamic.Dispatch("XSI.Application").Application
> """

So, when using the built-in Python distribution (as opposed to an external one?)
I don't need to dispatch at all?

And:

> By calling "win32com.client.Dispatch", you're using a shortcut to a high
> level set of functions including "win32com.client.dynamic.Dispatch".

That's what I figured, but if I'm ultimately calling the same functionality within that module,
so why do I get an error with timer events using one (the shortcut?), but not the other?
Is that a Python problem, or a Softimage problem?
Are other SDK components except timer events adversely affected as well?
To put it differently: Should one never use "win32com.client.Dispatch" and instead always use "win32com.client.dynamic.Dispatch", and even that only when
the code needs to be backwards compatible with Versions of Softimage before it was bundled with Python?

[Luc-Eric Rousseau]

I think that background info made things very complicated, skip it for now.

your error messages says "I can't find that attribute in the cached
python version of this object"

using win32com.client.Dispatch() uses either its cache if available,
or queries the object directly

using win32com.client.dynamic forces to by-pass the cache and query
the object directly (i.e. always assume that objects can have new
methods and attributes)

so.. going through dynamic would be slower but avoids python COM cache
problems, which I have heard happen a lot. (the SDK person who knows
this stuff is on vacation, so all you'll get total is stuff I vaguely
remember..)

it's harmless for you to use the method that works all the time, they
are both compatible with every version of the product and python.

you shouldn't need to know anything about python and COM IDispatch..,
but if you like pain you can read this
http://oreilly.com/catalog/pythonwin32/chapter/ch12.html

That book will not answer anything about this particular problem,
because I think this is the recurrent problem with the caching in
pywin which is more likely with XSI than another app like Excel.

We implemented a solution in Softimage 2013, "SOFT-2184 SDK Python:
Pywin cache breaks
virtual tables." It's possible some classes were not addressed.

If you're using 2013 and have a problem with a class, log the issue
with support and reference this bug (SOFT-2184) Tell them "Jean-Luc"
sent you (some people do this..)


..ok now back to Maya....

[Stefan Kubicek]

Thanks a lot for that comprehensive explanation Luc-Eric, that's all I needed :-)

> ..ok now back to Maya....

:-(

[Eric Thivierge]

Why are you sad? He's the one suffering! :P

Thanks for chiming in Luc-Eric.

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com