Maybe it's not your installation of Windows that's messed up, but just a
third party driver. Or someone has mis-configured something on the server.
This net share Z: drive: what's the technology / software that's behind
it? Is it a standard Windows share, or a third-party driver? (If it's a
st
"... not a valid Win32 application" sounds like a 32/64-bit issue to me.
The 32/64-bit version of python you're running: does it match the DLLs?
On 2017-12-14 6:10 PM, Kurt Eilander wrote:
Hey all,
I recently noticed that pythonwin comes with a scintilla wrapper.
Seems USEFUL! so I decided
I encountered the same mysterious symptom, but in a completely different
context. DLLs mis-matched. Might be of use to you...
http://curl.haxx.se/mail/curlpython-2014-05/0010.html
On 2014-05-26 9:16 PM, Mark Hammond wrote:
I see on python-list that this was solved by running the postInstall
sc
Find and activate it by matching its window title.
import win32com.client
shell = win32com.client.Dispatch('WScript.Shell')
if shell.AppActivate('Explorer'): # put a better match here.
print 'Did it.'
On 2014-03-19 5:32 AM, Jacob Kruger wrote:
If, for example, I use something like following
On 2013-12-18 12:34 PM, Tim Roberts wrote:
Jim Bell wrote:
I have two COM servers.
4. Looks for CLSID in HKCR\CLSID\{4...}, doesn't find it.
*5. **Stops looking and gives up, **throwing pywintypes.com_error:
(-2147221164, 'Class not registered', None, None)*
So why does
I have two COM servers. One works, the other doesn't, using the same
python client code, which seems to work differently behind the scenes.
I'm profiling both with SysInternals' ProcMon. Windows7x64, running
32-bit python 2.7.3. The python code isn't much more than:
import sys, os
impo
rProgID("The.ClassId")
# wrap the dumb object in the generated class
ob = kls(ob)
or with makepy -i, something like:
import somelib
# wrap the dumb object in the generated class
ob = somelib.TheClassName(ob)
Hope that answers the question!
Mark
On 17/12/2013 11:15 AM, Jim Bell wrote
I have a somelib.dll/somelib.tlb that doesn't register, and I want to
bypass the gen_py mechanism to package it better. I run makepy -o
somelib.py.
I should be able to instantiate it more directly, not through
client.Dispatch(), shouldn't I? Manually wrap it analogously to the server?
I see
win32com.server.util
import win32com.universal
On 2013-12-15 8:54 PM, Mark Hammond wrote:
On 15/12/2013 8:28 AM, Jim Bell wrote:
I've been though all the demos and scoured the web, and am stumped. But
I think I'm close. I have a 3rd-party .dll/.tlb. I run makepy.py and it
works fine. I need
I've been though all the demos and scoured the web, and am stumped. But
I think I'm close. I have a 3rd-party .dll/.tlb. I run makepy.py and it
works fine. I need to pass a callback interface, which they define,
into one of their functions. Here's where I'm stumped.
gencache.EnsureModule('{F8
10 matches
Mail list logo