--- Thomas Heller <[EMAIL PROTECTED]> wrote:
> Ed Blake schrieb:
> > I just tested under comtypes 0.3 and 0.4 with Autocad 2008. I get this
> > exception for both when using CreateObject:
> > ######################################################################
> >>>> acad = client.CreateObject("AutoCAD.Application")
> > Traceback (most recent call last):
> > File "<input>", line 1, in <module>
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 203,
> > in CreateObject
> > return _manage(obj, clsid, interface=interface)
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 171,
> > in _manage
> > obj = wrap(obj)
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 122,
> > in wrap
> > typeattr = tinfo.GetTypeAttr()
> > File "D:\Python25\Lib\site-packages\comtypes\typeinfo.py", line 262, in
> > GetTypeAttr
> > return _deref_with_release(self._GetTypeAttr(), self.ReleaseTypeAttr)
> > COMError: (-2147418111, 'Call was rejected by callee.', (None, None,
> None, 0,
> > None))
> > ######################################################################
> >
> > I think this happens because comtypes is trying to talk to Autocad before
> it
> > is finished its post startup initialization (loading modules, CUI, lisp
> > files).
>
> Hm, is this a bug in Autocad, or is comtypes behaving wrong here; does this
> error code mean we have to wait a little and retry the call? How do other
> COM clients, like VB or pywin32, behave?
>
I think this is their (Autodesk's) intended behaviour. This is the same
error you receive if a modal dialog is shown by the program or a command is
already running.
> > Using client.GetActiveObject on the other hand successfully generates the
> > Autocad modules and returns a pointer to the first running instance. It
> > doesn't work if Autocad isn't running though.
> >
> > BTW Thomas: I had to switch back to version 0.3.3 because something broke
> > between that version and the current.
>
> With this remark I assume you mean the code below, right?
Right
>
> > When I try to get a pointer to
> > Microstation under 0.4.1 I get this:
> > ######################################################################
> >>>> usta = client.GetActiveObject("MicroStationDGN.Application")
> > # Generating comtypes.gen._CF9F97BF_39F2_4B8E_835C_8BE9E99DAF5B_0_8_0
> > Traceback (most recent call last):
> > File "<input>", line 1, in <module>
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 166,
> > in GetActiveObject
> > return _manage(obj, clsid, interface=interface)
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 171,
> > in _manage
> > obj = wrap(obj)
> > File "D:\Python25\Lib\site-packages\comtypes\client\__init__.py", line
> 134,
> > in wrap
> > mod = GetModule(tlib)
> > File "D:\Python25\lib\site-packages\comtypes\client\_generate.py", line
> > 100, in GetModule
> > is_current, mod = _CreateWrapper(tlib, pathname)
> > File "D:\Python25\lib\site-packages\comtypes\client\_generate.py", line
> > 218, in _CreateWrapper
> > mod = _my_import(fullname)
> > File "D:\Python25\lib\site-packages\comtypes\client\_generate.py", line
> 14,
> > in _my_import
> > return __import__(fullname, globals(), locals(), ['DUMMY'])
> > File
> >
>
"D:\Python25\lib\site-packages\comtypes\gen\_CF9F97BF_39F2_4B8E_835C_8BE9E99DAF5B_0_8_0.py",
> > line 223, in <module>
> > ( ['retval', 'out'], POINTER(_midlSAFEARRAY(POINTER(_DataBlock))),
> 'pVal'
> > )),
> > File "D:\Python25\Lib\site-packages\comtypes\safearray.py", line 18, in
> > _midlSAFEARRAY
> > sa_type = _make_safearray_type(itemtype)
> > File "D:\Python25\Lib\site-packages\comtypes\safearray.py", line 46, in
> > _make_safearray_type
> > raise TypeError(itemtype)
> > TypeError: <class 'comtypes.POINTER(_DataBlock)'>
> > ######################################################################
> >
> > Something to do with the safearray refactor?
>
> In comtypes 0.4.1, safearrays containing com pointers are not implemented.
> They are, though, in the current SVN version. I wanted to release the next
> version
> after another MicroStation bug was examined, but the OP did not yet respond
> to
> my question. Maybe you can help; or I should release anyway? See
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1919272&group_id=115265&atid=692940
>
> Thomas
>
I can't figure out what that uuid is for, but it looks similar to the id of
one of my generated modules? I don't think you can interpret unique
identifiers that way, but if I'm right it means his modules didn't generate
correctly in the first place. I looked in my generated modules and in the
typelib but couldn't find anything relevant. Even though I have access to
Microstation I can't reproduce the error because I have never and probably
will not use the database linkage feature. I would suggest the user look at
using an alternate method if regenerating his Microstation modules doesn't
work - either send keyin commands, use xdata/datablocks/tag data, or access
the database directly from Python...
I think you should make a release, if nothing else it will shake out some new
bugs. BTW is there any new server side stuff in the next release? I've got
this crazy idea about automating Microstation by calling out to Python that
I'd like to try. I think it would be easier to get distributed where I work
if I can just package up a server and a (dummy) vba script...
Ed Blake
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
