How to increase PythonWin v2.0: COM browser limits?

[Ben Hutchings]

"Twan van der Schoot" <twanvds at xs4all.nl> writes:
<snip>
> To reproduce the problem: On a heavily used NT 4.0 system with a lot of
> registered COM stuff, start Pythonwin version 2.0 go to the menu entry: COM
> Browser to start the COM browser and expand the "Registered Categories"
> branch in the tree view.

This happens on my computer running Windows 2000 as well.

<snip>
> Pythonwin shows in the interactive window a backtrace on an exception.  The
> culprit raising this exception was the response:
> 
> File "D:\Python20\win32com\client\util.py", line 53, in __GetIndex
>     result = self._oleobj_.Next(1)
> pywintypes.com_error: (-2147024882, 'Not enough storage is available to
> complete this operation.', None, None)
> win32ui: Exception in OnNotify() handler
> 
> Something suggests that the number of registered objects is too large for
> the COM browser.

No, that's almost certainly *not* it.  For a start 'Registered
Categories' are entirely different from registered classes, and there
are likely to be very few of them on your computer.

> As I've -of course- the sources available, I was wonder if
> there is some parameter which I can increase to solve the problem.  Or am I
> running into limitations of the treeview control of MS Windows?

No, not that either.  'Out of memory' error messages are very often
the result of a programmer incorrectly assuming that some operation
can only fail due to lack of memory.

In fact, by adding a print statement to the loop that's iterating over
the categories to add them to the tree, I discovered that it yields
more or less the same results as OLEView (a similar program available
from Microsoft).  The exception is only raised after these results
have been returned.

The wrapper for COM enumerators, in true Pythonic style, does not
check the size of the collection in advance, but attempts to read
items until this yields an error.  I think that the category
enumerator implementation is reporting the no-more-items error in the
wrong way (returning E_OUTOFMEMORY rather than S_FALSE), so the
wrapper does not translate it into an IndexError exception which
would cause the loop to terminate successfully.  OLEView probably
just doesn't check for the error but displays what it already got.

-- 
Any opinions expressed are my own and not necessarily those of Roundpoint.