Are we looking/expecting to obtain the same equivalent functionality and
support for all win32com on win64 platforms shortly ?
Dominick Lauzon
___
python-win32 mailing list
python-win32@python.org
Hello,
I am tring to work on Excel File through python.
I am using Python 2.4.2 and work on xp with an administration authorization.
I implimented like that:
*
*
**
...
import win32com.client
...
class
Regardless of what 'we' are expecting shortly, we can already find this
support if only we looked (for python 2.6 anyway - other versions will
require us to build it ourselves using vs2008)
Mark.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Dominick Lauzon
Sent:
[EMAIL PROTECTED] wrote:
I am tring to work on Excel File through python.
I am using Python 2.4.2 and work on xp with an administration authorization.
I implimented like that:
*
*
**
...
import win32com.client
Ok, perhaps this will be useful.
(Neither of these examples include the core arguments of the methods,
just the ones specific to InvokeTypes)
What I call a method from I1, it calls _oleobj_.InvokeTypes with the
following arguments:
18, 0x0, 1, (24, 0), ((8, 1),)
When I use the method from I2,
Trent Mick wrote:
Given that my suggestion is no panacea, perhaps it is better to just leave it
at status quo and tell the user about the requirement to update their PATH.
Thoughts?
Trent
I have come across this issue, and am equally unsatisfied with the
solutions I've come up with so
Alec Munro wrote:
Ok, perhaps this will be useful.
(Neither of these examples include the core arguments of the methods,
just the ones specific to InvokeTypes)
What I call a method from I1, it calls _oleobj_.InvokeTypes with the
following arguments:
18, 0x0, 1, (24, 0), ((8, 1),)
When I
Hello all,
I am attempting to automate Sourcesafe access.
Here is a sample session:
import sys
sys.version
'2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]'
sys.subversion
('CPython', 'tags/r252', '60911')
sys.platform
'win32'
sys.getwindowsversion()
(5, 1, 2600, 2,
Thanks for the clarification Tim.
My root problem is still the Library not registered issue. As far as
how it was registered:
* I maintain a dll that defines a class that implements I1 and I2. I
use regsvr to register this dll.
* I1 and I2 come from a third party, and in order for my dll to
I'm afraid I've missed most of the context here:
I have come across this issue, and am equally unsatisfied with the
solutions I've come up with so far. all of them require the user to
know
too much about what's going on, and does not make the import just
work.
what if we added a python
Alec Munro wrote:
Thanks for the clarification Tim.
My root problem is still the Library not registered issue. As far as
how it was registered:
* I maintain a dll that defines a class that implements I1 and I2. I
use regsvr to register this dll.
* I1 and I2 come from a third party, and
Alec Munro wrote:
I've searched through the registry for the GUIDs I found associated
with the CLSIDs of the classes. They seem to be IIDs of type
libraries.
The first one, associated with I1, seems to refer to a _basicUHI.tlb
file that was distributed with SDK the third-party provides for
I'm still a little lost too, but:
* I maintain a dll that defines a class that implements I1 and I2. I
use regsvr to register this dll.
* I1 and I2 come from a third party, and in order for my dll to work
properly, it has to implement them (actually I2 is optional).
* I don't know how I1
13 matches
Mail list logo
