Hi Matteo,
Thanks for the suggestions. I have integrated the win32trace module into my
frozen app. Here is my final code:
from quickwho_main import quickwhoApp
import time
import tempfile
from win32com.server.exception import COMException
import winerror
import win32com.server.register
import win32traceutil
import sys
sys.stdout = open('C:/Users/Kevin/Desktop/my_stdout.log', 'w')
sys.stderr = open('C:/Users/Kevin/Desktop/my_stderr.log', 'w')
#expose basic functionality to COM
class QuickWho_Domain:
_public_methods_ = ['GetDomain']
_reg_progid_ = 'QuickWho.Application'
_reg_clsid_= '{9F825846-F10B-47DD-91E8-88DA93C1A05E}'
def GetDomain(self, domain):
try:
app.searchfield.delete(0, 'end')
app.searchfield.insert(0, str(domain))
app.getInfo()
time.sleep(1)
alltext=app.getData()
tempfile = tempfile.gettempdir()+ '/urltext.txt'
data = open(tempfile, 'r')
finaltext = data.read()
data.close()
return finaltext
except Exception ,ex:
exMsg='Unable to retrieve domain data '+str(ex)
raise COMException(desc=exMsg,
scode=winerror.E_FAIL)
print "*"*20
import win32com.server.register
sys.argv.append('--debug')
win32com.server.register.UseCommandLine(QuickWho_Domain)
print "*"*20
try:
app = quickwhoApp(None)
app.mainloop()
except Exception ,ex:
print "error !! " + str(ex)
(I put the code into a frozen app because it isn’t practical to debug the app
itself when run as a Python module—it won’t be deployed that way.)
I did get some debugging output, though not what I expected:
Exception in Tkinter callback
Traceback (most recent call last):
File "Tkinter.pyc", line 1410, in __call__
File "quickwho_main.pyc", line 159, in <lambda>
File "quickwho_main.pyc", line 253, in getInfo
File "subprocess.pyc", line 537, in check_output
File "subprocess.pyc", line 672, in __init__
File "subprocess.pyc", line 784, in _get_handles
File "subprocess.pyc", line 823, in _make_inheritable
WindowsError: [Error 6] The handle is invalid
This appears to be related to the bug logged at
http://bugs.python.org/issue3905. My app makes use of subprocess to obtain
various bits of data that it then parses and displays in its UI. For what it’s
worth, injecting the trace module into my frozen app causes no output to
appear at all in the app itself, and returns the error above; the trace module
seems to trigger the suprocess bug. However, it seems to have no bearing at all
on the failure of VBScript to create a COM object from my application, and the
debugging output logged to my stdout/stderr file did not yield any insight on
that.
I investigated whether running the mainloop() in the app might interfere with
the application receiving the COM request from the Windows Script Host, but
commenting out the mainloop only caused the app to crash (since Tkinter apps
require a mainloop to run).
The bottom line of all this investigation is that I am no closer to
understanding why my Tkinter app does not respond to the CreateObject request
from VBS. It appears that those requests simply disappear into a black hole. It
also appears that integrating a GUI toolkit with its own event loop in Python
may not be very practical with a COM server (see
http://trac.wxwidgets.org/ticket/12105 for some other issues with wxPython and
COM). Unfortunately, this means my best option is probably to move ahead
without COM support.
Thanks again for your help.
--Kevin _______________________________________________
python-win32 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-win32
