I am trying to put the stack trace into a file, since I cannot copy and
paste from the cmd line output. Is there a way to do this? Also, if you run
the file (assuming you have all the dependencies) the error happens as soon
as you press windows-`. You can change "speaker.say" to "print" and comment
out the line creating the speaker object so that you do not have to install
sayTools.
Have a great day,
Alex
Email: mehg...@gmail.com
----- Original Message -----
From: "Tim Golden" <m...@timgolden.me.uk>
Cc: <python-win32@python.org>
Sent: Friday, January 15, 2010 4:00
Subject: Re: [python-win32] WMI troubles!
On 15/01/2010 05:05, Alex Hall wrote:
Hello all,
I just joined this list. I am pretty new to Python, but I really like and
hope to get more into it;
Welcome to the list. And to Python.
Anyway, onto the problem. I am working on a simple resource monitor (I
have
never found one that works well with screen readers, so I am writing
one). I
am using python2.6 with all the win32 libs installed. My monitor will use
wmi to get all of its information, and it was going pretty well until a
few
hours ago, when I started receiving seemingly random errors.
What would definitely help, and this is general advice for posting
to technical groups, is the exact error you received -- the traceback
which looks something like this:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "c:\work_in_progress\wmi\trunk\wmi.py", line 1124, in __getattr__
return getattr (self._namespace, attribute)
File "c:\python26\lib\site-packages\win32com\client\dynamic.py", line
512, in __getattr__
raise AttributeError("%s.%s" % (self._username_, attr))
AttributeError: winmgmts:.Win32_Processx
In addition -- and I appreciate that this isn't always easy -- is
the smallest self-contained code example which will fail every time.
Apart from making it easier for people to help you out, it sometimes
makes the source of the error clearer even to you, the developer.
I don't have time now, but I will get to this later on today. The
likeliest cause is that PyHook is introducing a threading context
which is causing problems with the COM-based WMI stuff. Your early
CoInitialize is a nod in the right direction, but unfortunately
redundant where you've put it at the top of the main thread.
But sight of the traceback should help clarify things considerably.
TJG
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
