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
[email protected]
http://mail.python.org/mailman/listinfo/python-win
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 Python_skript
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: Wednesday,
[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 win32co
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, i
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 far.
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),)
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
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 w
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 p
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 par
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
oops, sorry, I suppose I shouldn't be deleting so much of the message
history. ;)
the specific circumstance that I've come across is with a non-admin
install of the win32 module. if I run python from the python directory
(so that the current directory is the directory where pywintypes25.dll
l
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
14 matches
Mail list logo
