pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 21:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-30 18:28

Message:
Logged In: YES 
user_id=14198
Originator: NO

I think this should work OK.  The out params seem harder than they should
be, but after a few false starts, this is the best I can come up with.  The
cost for no named params should be low.  Let me know what you think...
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-29 16:32

Message:
Logged In: YES 
user_id=771074
Originator: NO

I don't see anything in the docs to indicate that the sequential
order of DISPIDs can't be depended upon.  One thing we'd have
to be careful of is missing args.  I guess the tuple could be
created with the max of the DISPIDs, and we could insert an
ArgNotFound object for any args not passed.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-29 14:07

Message:
Logged In: YES 
user_id=14198
Originator: NO

Actually, I think there might be an easier way.  The docs for
ITypeInfo::GetIDsOfNames says "The IDs of parameters are 0 for the first
parameter in the member function's argument list, 1 for the second, and so
on" and I'm not aware of a way to override that in the IDL.  So the point
of GetIDsOfNames is when you do *not* know about the params - all you know
is the names of params presented to you.  If you pass the entire set of
param names to GetIDsOfNames, you'd always get back an array from 0->n.

So for our purposes, this is enough information - we can just treat the
dispID as an offset into our arg tuple.  Creating the tuple etc becomes a
little more complicated, but thats OK, especially if we optimize the 'no
named params' case.

does that make sense?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-29 13:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

>From playing around inside the python event code, it looks like the type
info may be available in a roundabout way:

        ti=self._oleobj_.GetTypeInfo(0)

The returned type info is for the WorkBook itself, but the event
source type info should be locatable from there (I think).

The gateway object stashes away a reference to the class instance that's
passed
as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you
can
get the object that provides the type info like this:

	PyObject *_obj_, *_oleobj_;
	_obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_");
	if (_obj_)
		_oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_");

That's as far as I've got for right now.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-28 08:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yeah, I'm a little confused about that page - but it seems pretty obvious
that every Excel related call we receive does indeed have index[0] of the
named items being a dispid of zero, and that this corresponds to the first
arg.  I understand that this isn't guaranteed though (and yeah, it is
apparently not even what is recommended according to that page.)

I don't think we can use GetTypeInfo() in the way you suggest.  Consider
this Excel example - we don't have a pointer to an Excel object, only one
of our objects that implements an interface defined by Excel.  I'm not sure
how the PyGatewayBase code at that point could determine the dispids as
defined in the excel typelib.  The only way I can see it working is to have
makepy include info in the class it generates, and this code could call
back on the policy to resolve the dispids to names.  This policy code could
sniff the properties written to the generated class, or if they don't
exist, just do what is done now.  Note that I do *not* think we can pass a
keywords arg dict, as that will defeat attempts to treat such as args as a
byref.

Or am I missing something regarding getting the ITypeInfo from the object?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-28 06:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-26 12:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 22:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 05:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2007-08-29 01:32

Message:
Logged In: YES 
user_id=771074
Originator: NO

I don't see anything in the docs to indicate that the sequential
order of DISPIDs can't be depended upon.  One thing we'd have
to be careful of is missing args.  I guess the tuple could be
created with the max of the DISPIDs, and we could insert an
ArgNotFound object for any args not passed.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-28 23:07

Message:
Logged In: YES 
user_id=14198
Originator: NO

Actually, I think there might be an easier way.  The docs for
ITypeInfo::GetIDsOfNames says "The IDs of parameters are 0 for the first
parameter in the member function's argument list, 1 for the second, and so
on" and I'm not aware of a way to override that in the IDL.  So the point
of GetIDsOfNames is when you do *not* know about the params - all you know
is the names of params presented to you.  If you pass the entire set of
param names to GetIDsOfNames, you'd always get back an array from 0->n.

So for our purposes, this is enough information - we can just treat the
dispID as an offset into our arg tuple.  Creating the tuple etc becomes a
little more complicated, but thats OK, especially if we optimize the 'no
named params' case.

does that make sense?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-28 22:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

>From playing around inside the python event code, it looks like the type
info may be available in a roundabout way:

        ti=self._oleobj_.GetTypeInfo(0)

The returned type info is for the WorkBook itself, but the event
source type info should be locatable from there (I think).

The gateway object stashes away a reference to the class instance that's
passed
as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you
can
get the object that provides the type info like this:

	PyObject *_obj_, *_oleobj_;
	_obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_");
	if (_obj_)
		_oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_");

That's as far as I've got for right now.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yeah, I'm a little confused about that page - but it seems pretty obvious
that every Excel related call we receive does indeed have index[0] of the
named items being a dispid of zero, and that this corresponds to the first
arg.  I understand that this isn't guaranteed though (and yeah, it is
apparently not even what is recommended according to that page.)

I don't think we can use GetTypeInfo() in the way you suggest.  Consider
this Excel example - we don't have a pointer to an Excel object, only one
of our objects that implements an interface defined by Excel.  I'm not sure
how the PyGatewayBase code at that point could determine the dispids as
defined in the excel typelib.  The only way I can see it working is to have
makepy include info in the class it generates, and this code could call
back on the policy to resolve the dispids to names.  This policy code could
sniff the properties written to the generated class, or if they don't
exist, just do what is done now.  Note that I do *not* think we can pass a
keywords arg dict, as that will defeat attempts to treat such as args as a
byref.

Or am I missing something regarding getting the ITypeInfo from the object?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-27 15:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 03:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-25 21:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 07:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 02:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 21:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-29 14:07

Message:
Logged In: YES 
user_id=14198
Originator: NO

Actually, I think there might be an easier way.  The docs for
ITypeInfo::GetIDsOfNames says "The IDs of parameters are 0 for the first
parameter in the member function's argument list, 1 for the second, and so
on" and I'm not aware of a way to override that in the IDL.  So the point
of GetIDsOfNames is when you do *not* know about the params - all you know
is the names of params presented to you.  If you pass the entire set of
param names to GetIDsOfNames, you'd always get back an array from 0->n.

So for our purposes, this is enough information - we can just treat the
dispID as an offset into our arg tuple.  Creating the tuple etc becomes a
little more complicated, but thats OK, especially if we optimize the 'no
named params' case.

does that make sense?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-29 13:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

>From playing around inside the python event code, it looks like the type
info may be available in a roundabout way:

        ti=self._oleobj_.GetTypeInfo(0)

The returned type info is for the WorkBook itself, but the event
source type info should be locatable from there (I think).

The gateway object stashes away a reference to the class instance that's
passed
as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you
can
get the object that provides the type info like this:

	PyObject *_obj_, *_oleobj_;
	_obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_");
	if (_obj_)
		_oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_");

That's as far as I've got for right now.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-28 08:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yeah, I'm a little confused about that page - but it seems pretty obvious
that every Excel related call we receive does indeed have index[0] of the
named items being a dispid of zero, and that this corresponds to the first
arg.  I understand that this isn't guaranteed though (and yeah, it is
apparently not even what is recommended according to that page.)

I don't think we can use GetTypeInfo() in the way you suggest.  Consider
this Excel example - we don't have a pointer to an Excel object, only one
of our objects that implements an interface defined by Excel.  I'm not sure
how the PyGatewayBase code at that point could determine the dispids as
defined in the excel typelib.  The only way I can see it working is to have
makepy include info in the class it generates, and this code could call
back on the policy to resolve the dispids to names.  This policy code could
sniff the properties written to the generated class, or if they don't
exist, just do what is done now.  Note that I do *not* think we can pass a
keywords arg dict, as that will defeat attempts to treat such as args as a
byref.

Or am I missing something regarding getting the ITypeInfo from the object?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-28 06:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-26 12:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 22:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 05:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2007-08-28 22:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

>From playing around inside the python event code, it looks like the type
info may be available in a roundabout way:

        ti=self._oleobj_.GetTypeInfo(0)

The returned type info is for the WorkBook itself, but the event
source type info should be locatable from there (I think).

The gateway object stashes away a reference to the class instance that's
passed
as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you
can
get the object that provides the type info like this:

	PyObject *_obj_, *_oleobj_;
	_obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_");
	if (_obj_)
		_oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_");

That's as far as I've got for right now.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yeah, I'm a little confused about that page - but it seems pretty obvious
that every Excel related call we receive does indeed have index[0] of the
named items being a dispid of zero, and that this corresponds to the first
arg.  I understand that this isn't guaranteed though (and yeah, it is
apparently not even what is recommended according to that page.)

I don't think we can use GetTypeInfo() in the way you suggest.  Consider
this Excel example - we don't have a pointer to an Excel object, only one
of our objects that implements an interface defined by Excel.  I'm not sure
how the PyGatewayBase code at that point could determine the dispids as
defined in the excel typelib.  The only way I can see it working is to have
makepy include info in the class it generates, and this code could call
back on the policy to resolve the dispids to names.  This policy code could
sniff the properties written to the generated class, or if they don't
exist, just do what is done now.  Note that I do *not* think we can pass a
keywords arg dict, as that will defeat attempts to treat such as args as a
byref.

Or am I missing something regarding getting the ITypeInfo from the object?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-27 15:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 03:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-25 21:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 07:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 02:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 21:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-28 08:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yeah, I'm a little confused about that page - but it seems pretty obvious
that every Excel related call we receive does indeed have index[0] of the
named items being a dispid of zero, and that this corresponds to the first
arg.  I understand that this isn't guaranteed though (and yeah, it is
apparently not even what is recommended according to that page.)

I don't think we can use GetTypeInfo() in the way you suggest.  Consider
this Excel example - we don't have a pointer to an Excel object, only one
of our objects that implements an interface defined by Excel.  I'm not sure
how the PyGatewayBase code at that point could determine the dispids as
defined in the excel typelib.  The only way I can see it working is to have
makepy include info in the class it generates, and this code could call
back on the policy to resolve the dispids to names.  This policy code could
sniff the properties written to the generated class, or if they don't
exist, just do what is done now.  Note that I do *not* think we can pass a
keywords arg dict, as that will defeat attempts to treat such as args as a
byref.

Or am I missing something regarding getting the ITypeInfo from the object?

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-28 06:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-26 12:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 22:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 05:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2007-08-27 15:57

Message:
Logged In: YES 
user_id=771074
Originator: NO

As far as I can tell, this fixes the Excel events that pass the named
args
sequentially.  I also tested it out with several different types of
events
from IE, which uses positional args.

However, unless I'm misreading the page on MSDN, the canonical order even
for named args is last arg first.  Again, that's not a requirement.
Even though this patch works for the specific Office events in question,
it may break com servers that fire events with the named args in reverse
order, which would currently be called correctly.

The only way I can see to make sure the args are passed correctly in all
cases
is to do a reverse mapping from the DISPID's to the names.  This would
require that
the object have type info, but we already require that for
DispatchWithEvents.

A basic outline might look something like this:
    If named args are passed, use GetTypeInfo to retrieve the server's
type info
    Use ITypeInfo->GetNames for the invoked member id, which returns the
names
        in the order in which they're to be passed to the python method.
    Call GetIDsOfNames with the above names to retrieve their DISPID's in
the same order
    Loop over DISPID's for the named args, and use the order of the
DISPID's returned from above
        to build the arg tuple in the order the names are returned
        Alternately, we could use keywords as you suggested and build an
arg tuple
            and dict to be passed to the python implementation of the
method.
    On return, use the ordered DISPID's to determine which VT_BYREF params
receive
        the values returned from python.

This looks to be fairly expensive in terms of processing time, but
apparently
named args aren't frequently used so there shouldn't be too much of a
performance
hit in the general case.



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 03:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-25 21:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 07:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 02:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1573578 ] IActiveScriptSiteInterruptPoll not used

[SourceForge.net <no...@so...>]

Bugs item #1573578, was opened at 2006-10-09 10:24
Message generated for change (Comment added) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1573578&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: IActiveScriptSiteInterruptPoll not used

Initial Comment:
QueryContinue of IActiveScriptSiteInterruptPoll is
never called.

Our app uses this function to perform idle events and
allow the user to cancel scripts.

This function should be called from somewhere within
the Python Active Script Engine.

----------------------------------------------------------------------

>Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-27 12:37

Message:
Logged In: YES 
user_id=1585378
Originator: YES

We solved it ourselves by using event filters, but cancel still doesn't
work.

I guess the problem is that Python itself doesn't process Windows messages
- the libs do it themselves.

You could close this item if you want to. Maybe it
(IActiveScriptSiteInterruptPoll never called) should be documented
somewhere?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 10:48

Message:
Logged In: YES 
user_id=14198
Originator: NO

I can't think of a feasible way for this to happen as Python code is
running - or are you suggesting something different?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1573578&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1573578 ] IActiveScriptSiteInterruptPoll not used

[SourceForge.net <no...@so...>]

Bugs item #1573578, was opened at 2006-10-09 18:24
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1573578&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: IActiveScriptSiteInterruptPoll not used

Initial Comment:
QueryContinue of IActiveScriptSiteInterruptPoll is
never called.

Our app uses this function to perform idle events and
allow the user to cancel scripts.

This function should be called from somewhere within
the Python Active Script Engine.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:48

Message:
Logged In: YES 
user_id=14198
Originator: NO

I can't think of a feasible way for this to happen as Python code is
running - or are you suggesting something different?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1573578&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1582720 ] Python long integers aren't translated to Variant/long

[SourceForge.net <no...@so...>]

Bugs item #1582720, was opened at 2006-10-23 19:02
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1582720&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matt (matthiaskirst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python long integers aren't translated to Variant/long

Initial Comment:
Since Version 208 Python long integers are not 
translated to Variant/long type anymore.
I think that is on purpose since long integers have 
undefined precision. 
But isn't it possible to gracefully convert to Variant/
long like in the versions up to 207?
Maybe there is existing code around that can be broken 
by the above mentioned behaviour (like my one).

Test code:

import pythoncom

class Test:
    _public_methods_ = [ 'Test' ]
    _reg_progid_ = "Python.COMTest3"
    _reg_clsid_ = "{2D7DD06A-83D3-4F31-848C-
57AFA22A650D}"
    _reg_clsctx_ = pythoncom.CLSCTX_INPROC_SERVER

    def Test( self ):
        a = long( 0 )
        return a
    
if __name__ == "__main__":
    import win32com.server.register
    print "Registering..."
    win32com.server.register.UseCommandLine( Test )

In VB:

Private Sub Form_Load()

    Dim p As Object
    Dim a
    
    Set p = CreateObject("Python.COMTest3")
    a = p.Test()

End Sub

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:39

Message:
Logged In: YES 
user_id=14198
Originator: NO

Yes, we should still use VT_I4 if the value fits, and I broke that.  I
just fixed it, so your example should work again in the next build.

Checking in com/win32com/src/oleargs.cpp;
new revision: 1.39; previous revision: 1.38

----------------------------------------------------------------------

Comment By: yiwamoto (yiwamoto)
Date: 2006-12-12 21:59

Message:
Logged In: YES 
user_id=1666448
Originator: NO

I supporse this problem occurs under VB(VBA) only.
Since version 208, type conversion(Python type --> COM variant type)
program
uses 'VT_UI4'(unsigned int) COM variant type instead of 'VT_I4'(signed
int).

But, VB(VBA) don't support unsigned int type.
I don't know how to solve this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1582720&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 21:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-27 18:13

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks Roger - nice work tracking that down :)  That is pretty nasty :(  A
proper fix isn't trivial either as there is no obvious way to map the
dispid to the name in this code.  We'd probably end up needing to have
makepy include this param information and have our code call back into our
policy to resolve things.  Its harder given the way we return BYREF params
(ie, its not as simple as leaning on Python's keyword capabilities)

In the short term, I think the existing checks can remain - their intent
is kinda reasonable even if they are wrong :)  We should then unpack the
named params in the reverse order.  This would then work for people who set
their params up the "recommended"[1] way - and this is what Office seems to
do, as per these examples.

I've attached the start of a patch which appears to fixup the main issue,
but still fails to handle "out" params correctly (but the test suite
changes pick that up) - it might be a few days before I can look at this
again.  In the meantime, if you (Roger) can find the time to review the
patch I'd appreciate it, and it seems somewhat strange that the args
*passed* are reversed in the 'named' case, but the test suite changes
appear to match both the docs and the description in that MS article.

[1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx
File Added: bug-1648655.patch

----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2007-08-26 12:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 22:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 17:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1587023 ] ActiveScript, LazyDispatchItem doesn't rename properties

[SourceForge.net <no...@so...>]

Bugs item #1587023, was opened at 2006-10-30 19:19
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587023&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: ActiveScript, LazyDispatchItem doesn't rename properties

Initial Comment:
The problem seems to be that LazyDispatchItem doesn't
remap the
properties as DispatchItem does. If I disable the
LazyDispatchItem
generation in MakeOleRepr and always return a
DispatchItem object, the
script works as expected.

See the following thread for more information:

http://mail.python.org/pipermail/python-win32/2006-October/005174.html

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-26 13:42

Message:
Logged In: YES 
user_id=14198
Originator: NO

I struggled to reproduce this, but for reasons related to the test suite
rather than because the issue doesn't exist.  Its also worth nothing that
dynamic objects don't support Get/Set properties either, but I see no way
to integrate that functionality in a sane way.  I also don't see a better
options for handling it with "lazy" items, so I'm checking your patch (with
a minor change) in.

Thanks!
Checking in dynamic.py;
new revision: 1.22; previous revision: 1.21

----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 16:39

Message:
Logged In: YES 
user_id=1585378
Originator: YES

This problem only occurs when working with a typed COM Object (not
IDispatch) wrapped by LazyDispatch. This is the case when running Python
Active Scripts and executing normal scripts without the gen_py interface.

When I use such an object with a Set property, Python uses the wrong
property name (with Set) when calling typecomp.Bind.

I've found a better solution:

Index: dynamic.py
===================================================================
--- dynamic.py  (revision 36121)
+++ dynamic.py  (working copy)
@@ -377,6 +377,8 @@
               for i in ALL_INVOKE_TYPES:
                       try:
                               x,t = typecomp.Bind(attr,i)
+                               if x==0 and (attr[:3] == 'Set' or attr[:3]
== 'Get'):
+                                       x,t = typecomp.Bind(attr[3:], i) #
strip get / set
                               if x==1:        #it's a FUNCDESC
                                       r =
olerepr._AddFunc_(typeinfo,t,0)
                               elif x==2:      #it's a VARDESC



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587023&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1648655 ] Wrong args order with event handler

[SourceForge.net <no...@so...>]

Bugs item #1648655, was opened at 2007-01-31 05:09
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: atsuo ishimoto (ishimoto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong args order with event handler

Initial Comment:
Order of args doesn't match with prototype generated by makepy.

To reproduce, please run script below and Save workbook on the Excel.

# <<<<<< BEGIN >>>>>>
import win32com.client

class WorkbookEvent:
    def OnBeforeSave(self, SaveAsUI, Cancel):
        print "OnBeforeSave", SaveAsUI, Cancel
        return False

xl = win32com.client.Dispatch("Excel.Application")
xl.Visible = 1
wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent)
while 1:
    pythoncom.PumpWaitingMessages()

# <<<<<< END >>>>>>

When I save workbook, WorkbookEvent.OnBeforeSave called with 
SaveAsUI=False and Cancel=False. But on SaveAs, args passed are 
SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and 
Cancel=False. 

Python2.4.3,pywin32-210,MS-Excel 2000



----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2007-08-25 21:33

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the problem is that the args wind up backwards when they're passed
as named args.

For a different event with 3 parms:
    def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel):
        print Sh, Target, Cancel
        return False
This prints
    False None <win32com.gen_py.Microsoft Excel 9.0 Object
Library._Worksheet instance at 0x21747576>

The first arg Sh should be the worksheet, but I get a
boolean as the first parm, and the worksheet ends up as the 3rd arg.

>From stepping through in the debugger, both of these events are passing
named parms.
The code that creates the arg tuple to pass to the event method isn't
doing any mapping
between names and DISPID's.  It only verifies that the named params are in
sequential
order (which they are not actually required to be).  However, it then goes
on to process
the named args in reverse order just as if they were positional args.


----------------------------------------------------------------------

Comment By: atsuo ishimoto (ishimoto)
Date: 2007-07-28 07:35

Message:
Logged In: YES 
user_id=463672
Originator: YES

Thank you for comment.
But same script with VB.NET, correct values are passed with correct
order.
So, I guess typelib is corrent.


Part of VB script follows.


    Private WithEvents e1 As Excel.Application

    Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal
SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles
e1.WorkbookBeforeSave
        MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel))
    End Sub
End Class




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-07-28 02:17

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry, but I can't see a bug of ours here.  It sounds like the type info
Excel gives out is wrong - otherwise I'd expect *all* params to be reversed
for all events, and I don't think that is the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1537569 ] missing documentation: missing .NET

[SourceForge.net <no...@so...>]

Bugs item #1537569, was opened at 2006-08-10 04:23
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1537569&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: v1.0 (example)
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Steve Strassmann (straz)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing documentation: missing .NET

Initial Comment:
On Windows XP, installing pywin32-209 for the first time.

  > setup.py install
  Building pywin32 2.4.209.0
  ...
  Warning - can't find an installed platform SDK
  error: The .NET Framework SDK needs to be installed   
  before building extensions for python.

OK, I am fairly clueless about windows development but
I'm fairly familiar with python on unix.

There is nothing in the documentation about requiring
.NET framework. Nothing about how to install it.

The Installation Problems Guide
(http://www.python.net/crew/mhammond/win32/InstallationProblems.html)
and FAQ
(http://www.python.net/crew/mhammond/win32/FAQ.html)
have no mention of this.

The home page (http://www.python.net/crew/mhammond/win32/)
mentions requiring mfc71.dll. I have this installed in
my windows system32 directory.

The README.txt in the distribution (not available on
the site) says "these extensions require MSVC7".
There's no mention of this on the web site.
What is this, and where do I get it?

There are no dates published with any of the releases -
not on the web site, not even in the manifest or readme
files. When were these files built?

So, what this bug really is:
If I need to be installing .NET, please add
documentation describing 
   (a) what do I install 
   (b) where do I get it from
   (c) how do I install it

Is it possible to just download a binary of win32api
without having to recompile from sources?

thank you very much,
 Steve


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-08-10 11:20

Message:
Logged In: YES 
user_id=14198

setup.py includes documentation on the various SDKs
required, and links where to get them.  Executing setup.py
with no args should print this for you.  That file refers to
the "Platform SDK", but the latest version of that SDK is
now known by MS as the '.NET Plaform SDK'.

Binaries are available from the 'files' section of this
sourceforge project.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1537569&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1587646 ] win32timezone: southern hemisphere daylight savings problem

[SourceForge.net <no...@so...>]

Bugs item #1587646, was opened at 2006-10-31 13:35
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587646&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cameron LEE (noremac_eel)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32timezone: southern hemisphere daylight savings problem

Initial Comment:
I found a bug in the win32timezone: It doesn’t handle
daylight savings for us poor southern hemispherians. 
The logic works great for the northerners as your
summer is in the middle of the year.  Ours however
straddles 2 years.

The following fixes that.  My logic was that if the dst
start month was higher than august, then you aren’t in
the north. 

 

    def dst( self, dt ):

        "Calculates the daylight savings offset
according to the datetime.tzinfo spec"

        if dt is None: return

        assert dt.tzinfo is self

        result = self.standardBiasOffset

 

        try:

            dstStart = self.GetDSTStartTime( dt.year )

            dstEnd = self.GetDSTEndTime( dt.year )

            if dstStart.month > 8:

                if not (dstEnd < dt.replace(
tzinfo=None ) <= dstStart) and not self.fixedStandardTime:

                    result = self.daylightBiasOffset

            else:

                if dstStart <= dt.replace( tzinfo=None
) < dstEnd and not self.fixedStandardTime:

                    result = self.daylightBiasOffset

        except ValueError:

            # there was an error parsing the time zone,
which is normal when a

            #  start and end time are not specified.

            pass

 

        return result

 

 


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-25 15:27

Message:
Logged In: YES 
user_id=14198
Originator: NO

This fix was previously checked in

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2006-11-01 01:07

Message:
Logged In: YES 
user_id=599869

One last time, this fix should work correctly.  I had the
wrong comparator in the last patch.

--- win32timezone.py	2006-01-03 04:12:38.000000000 -0500
+++ win32timezone.py	2006-10-31 08:55:03.487946900 -0500
@@ -12,7 +12,7 @@
 	This module may be tested using the doctest module.
 
 	Written by Jason R. Coombs (ja...@ja...).
-	Copyright © 2003.
+	Copyright © 2003-2006.
 	All Rights Reserved.	
 
 	To use this time zone module with the datetime module,
simply pass
@@ -67,13 +67,31 @@
 >>> tz = win32timezone.TimeZoneInfo( 'China Standard Time' )
 >>> tz == pickle.loads( pickle.dumps( tz ) )
 True
+
+>>> aest = win32timezone.TimeZoneInfo( 'AUS Eastern
Standard Time' )
+>>> est = win32timezone.TimeZoneInfo( 'E. Australia
Standard Time' )
+>>> dt = datetime.datetime( 2006, 11, 11, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2006-11-11 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 1, 12, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-01-12 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 6, 13, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-06-13 01:00:00'
+
 """
 from __future__ import generators
 
 __author__ = 'Jason R. Coombs <ja...@ja...>'
 __version__ = '$Revision: 1.5 $'[11:-2]
-__vssauthor__ = '$Author: mhammond $'[9:-2]
-__date__ = '$Modtime: 04-04-14 10:52 $'[10:-2]
+__sccauthor__ = '$Author: mhammond $'[9:-2]
+__date__ = '$Date: 04-04-14 10:52 $'[10:-2]
 
 import os, _winreg, struct, datetime
 
@@ -168,8 +186,15 @@
 		try:
 			dstStart = self.GetDSTStartTime( dt.year )
 			dstEnd = self.GetDSTEndTime( dt.year )
+			
+			if dstStart < dstEnd:
+				inDaylightSavings = dstStart <= dt.replace( tzinfo=None
) < dstEnd
+			else:
+				# in the southern hemisphere, daylight savings time
+				#  typically ends before it begins in a given year.
+				inDaylightSavings = not ( dstEnd < dt.replace(
tzinfo=None ) <= dstStart )
 
-			if dstStart <= dt.replace( tzinfo=None ) < dstEnd and
not self.fixedStandardTime:
+			if inDaylightSavings and not self.fixedStandardTime:
 				result = self.daylightBiasOffset
 		except ValueError:
 			# there was an error parsing the time zone, which is
normal when a


----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2006-11-01 00:50

Message:
Logged In: YES 
user_id=599869

Here is another version of the patch that addresses the
encoding issue.

--- win32timezone.py	2006-01-03 04:12:38.000000000 -0500
+++ win32timezone.py	2006-10-31 08:42:45.803675100 -0500
@@ -12,7 +12,7 @@
 	This module may be tested using the doctest module.
 
 	Written by Jason R. Coombs (ja...@ja...).
-	Copyright © 2003.
+	Copyright © 2003-2006.
 	All Rights Reserved.	
 
 	To use this time zone module with the datetime module,
simply pass
@@ -67,13 +67,31 @@
 >>> tz = win32timezone.TimeZoneInfo( 'China Standard Time' )
 >>> tz == pickle.loads( pickle.dumps( tz ) )
 True
+
+>>> aest = win32timezone.TimeZoneInfo( 'AUS Eastern
Standard Time' )
+>>> est = win32timezone.TimeZoneInfo( 'E. Australia
Standard Time' )
+>>> dt = datetime.datetime( 2006, 11, 11, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2006-11-11 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 1, 12, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-01-12 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 6, 13, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-06-13 01:00:00'
+
 """
 from __future__ import generators
 
 __author__ = 'Jason R. Coombs <ja...@ja...>'
 __version__ = '$Revision: 1.5 $'[11:-2]
-__vssauthor__ = '$Author: mhammond $'[9:-2]
-__date__ = '$Modtime: 04-04-14 10:52 $'[10:-2]
+__sccauthor__ = '$Author: mhammond $'[9:-2]
+__date__ = '$Date: 04-04-14 10:52 $'[10:-2]
 
 import os, _winreg, struct, datetime
 
@@ -168,8 +186,15 @@
 		try:
 			dstStart = self.GetDSTStartTime( dt.year )
 			dstEnd = self.GetDSTEndTime( dt.year )
+			
+			if dstStart > dstEnd:
+				inDaylightSavings = dstStart <= dt.replace( tzinfo=None
) < dstEnd
+			else:
+				# in the southern hemisphere, daylight savings time
+				#  typically ends before it begins in a given year.
+				inDaylightSavings = not ( dstEnd < dt.replace(
tzinfo=None ) <= dstStart )
 
-			if dstStart <= dt.replace( tzinfo=None ) < dstEnd and
not self.fixedStandardTime:
+			if inDaylightSavings and not self.fixedStandardTime:
 				result = self.daylightBiasOffset
 		except ValueError:
 			# there was an error parsing the time zone, which is
normal when a


----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2006-11-01 00:34

Message:
Logged In: YES 
user_id=599869

I'm sorry.  I did address this when I got the initial e-mail
from Cameron.  I had started to code a fix and then ran into
some difficulty with date ranges, so put it on my task list,
but hadn't gotten to it.  Thanks for bumping me on this.

I did the same thing as Mark at first, but then realized
that only addresses the issue for the latter part of the
year.  If the time in question is in January, for example,
the range of interest is ( GetDSTStartTime( dt.year-1),
GetDSTEndTime( dt.year ) ).

Therefore, I've coded the patch somewhat differently.  I
tried to do something more elegant, but it seems the best
approach for the southern hemisphere is to test for
exclusion from daylight savings time, as inclusion from
daylight savings time includes two distinct periods for a
given year.

Here is another patch with some additional test cases that
demonstrates correct functional behavior in all three parts
of the year for the southern hemisphere timezones.

Comments greatly appreciated.

Patch follows (as I don't appear to have access to submit
files).

--- win32timezone.py	2006-01-03 04:12:38.000000000 -0500
+++ win32timezone.py	2006-10-31 08:26:26.803675100 -0500
@@ -12,7 +12,7 @@
 	This module may be tested using the doctest module.
 
 	Written by Jason R. Coombs (ja...@ja...).
-	Copyright © 2003.
+	Copyright © 2003-2006.
 	All Rights Reserved.	
 
 	To use this time zone module with the datetime module,
simply pass
@@ -67,13 +67,31 @@
 >>> tz = win32timezone.TimeZoneInfo( 'China Standard Time' )
 >>> tz == pickle.loads( pickle.dumps( tz ) )
 True
+
+>>> aest = win32timezone.TimeZoneInfo( 'AUS Eastern
Standard Time' )
+>>> est = win32timezone.TimeZoneInfo( 'E. Australia
Standard Time' )
+>>> dt = datetime.datetime( 2006, 11, 11, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2006-11-11 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 1, 12, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-01-12 00:00:00'
+
+>>> dt = datetime.datetime( 2007, 6, 13, 1, 0, 0, tzinfo =
aest )
+>>> estdt = dt.astimezone( est )
+>>> estdt.strftime( '%Y-%m-%d %H:%M:%S' )
+'2007-06-13 01:00:00'
+
 """
 from __future__ import generators
 
 __author__ = 'Jason R. Coombs <ja...@ja...>'
 __version__ = '$Revision: 1.5 $'[11:-2]
-__vssauthor__ = '$Author: mhammond $'[9:-2]
-__date__ = '$Modtime: 04-04-14 10:52 $'[10:-2]
+__sccauthor__ = '$Author: mhammond $'[9:-2]
+__date__ = '$Date: 04-04-14 10:52 $'[10:-2]
 
 import os, _winreg, struct, datetime
 
@@ -168,8 +186,15 @@
 		try:
 			dstStart = self.GetDSTStartTime( dt.year )
 			dstEnd = self.GetDSTEndTime( dt.year )
+			
+			if dstStart > dstEnd:
+				inDaylightSavings = dstStart <= dt.replace( tzinfo=None
) < dstEnd
+			else:
+				# in the southern hemisphere, daylight savings time
+				#  typically ends before it begins in a given year.
+				inDaylightSavings = not ( dstEnd < dt.replace(
tzinfo=None ) <= dstStart )
 
-			if dstStart <= dt.replace( tzinfo=None ) < dstEnd and
not self.fixedStandardTime:
+			if inDaylightSavings and not self.fixedStandardTime:
 				result = self.daylightBiasOffset
 		except ValueError:
 			# there was an error parsing the time zone, which is
normal when a


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-10-31 16:22

Message:
Logged In: YES 
user_id=14198

It appears your editor changed the whitespace in the file,
and modified the utf8 'copyright' character.  I've attached
the changes as a patch and asked Jason to have a quick look.

Thanks,

Mark

----------------------------------------------------------------------

Comment By: Cameron LEE (noremac_eel)
Date: 2006-10-31 15:50

Message:
Logged In: YES 
user_id=284417

p.s. am in sunny Queensland  :-)

BrisVegus.

Cameron.

----------------------------------------------------------------------

Comment By: Cameron LEE (noremac_eel)
Date: 2006-10-31 15:48

Message:
Logged In: YES 
user_id=284417

hope this is what yu are after.

appended to bottom of module doctests

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-10-31 15:05

Message:
Logged In: YES 
user_id=14198

I meant to ask this before, but can you please also give me
an example of code that failed and works with the patch? 
I'm in Melbourne so should be able to test easily :)

Thanks

----------------------------------------------------------------------

Comment By: Cameron LEE (noremac_eel)
Date: 2006-10-31 14:24

Message:
Logged In: YES 
user_id=284417

yes, much nicer! :-)

also need to update value for dstend.

(attached)

Cheers,

Cameron.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-10-31 13:50

Message:
Logged In: YES 
user_id=14198

Wouldn't a better fix be to check if dstStart > dstEnd
rather than assuming something special about August?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587646&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1751177 ] Missing CF_DIBV5

[SourceForge.net <no...@so...>]

Bugs item #1751177, was opened at 2007-07-11 00:02
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1751177&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Pete Forman (pete_forman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing CF_DIBV5

Initial Comment:
The clipboard formats defined as attributes of win32clipboard and win32con do not include CF_DIBV5 = 18.  This was new in Windows 2000.  I observed it copying from Excel 2002 on XP.

See

http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/assoc.mspx

and winuser.h

pywin32 210 on Python 2.5.1.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-25 15:15

Message:
Logged In: YES 
user_id=14198
Originator: NO

Checking in lib/win32con.py;
new revision: 1.21; previous revision: 1.20
Checking in src/win32clipboardmodule.cpp;
new revision: 1.22; previous revision: 1.21

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1751177&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 19:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-25 15:09

Message:
Logged In: YES 
user_id=14198
Originator: NO

Checking in selecttlb.py;
new revision: 1.9; previous revision: 1.8

----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 16:31

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Yes, at least interactive makepy from pythonwin works without the int
calls (I even removed minor and major completely from selecttlb.py).

The bug doesn't appear with most typelibs, since their version numbers
aren't high enough. For me, this is the case with all the Microsoft Office
typelibs.

Note that the Microsoft office Typelib browser doesn't show the version
numbers at all. It only shows the typelib "helpstring". Maybe you should
remove the version number too?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-15 04:00

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks for that - at least this confirms that (a) they *should* be hex,
and (b) that even MS manages to get this wrong.  I'd prefer to simply
remove the int() calls alltogether, and then fix any code which still
assumes integers.  I've made that change locally, but I'm travelling, so
unable to fully test this until I get home.  I'd appreciate it if you could
make a similar change (ie, remove the int() calls, and the try/except block
completely) and see if anything else breaks for you.

----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 00:10

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Check out the following link:

http://support.microsoft.com/kb/816970



----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 00:05

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Not sure if there is a standard, but a simple version statement like the
following actually produces a a.0:

[
    uuid(...),
    version(10.0),
    helpstring(...)
]

library OURLIB
{
    ...

By googling around a bit there seems to be several apps using this scheme
(Corel Wordperfect 12)

Why disallow it in the first place?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 23:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1202339 ] Early binding of WMI Scripting V1.2 Library hides properties

[SourceForge.net <no...@so...>]

Bugs item #1202339, was opened at 2005-05-15 08:46
Message generated for change (Comment added) made by tojo2000
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1202339&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: Early binding of WMI Scripting V1.2 Library hides properties

Initial Comment:
Using the microsoft sample code located at
http://www.microsoft.com/technet/scriptcenter/scripts/python/ad/domains/addmpy01.mspx,
I find that the code will not run if the the scripting
library (Microsoft WMI Scripting V1.2 Library) is
configured for early binding (that is, I use the makepy
utility).  If I remove the early binding, the script
runs fine.

With early binding enabled, I get the following output:

--- begin output ---
Caption:
Traceback (most recent call last):
  File "C:\bin\domain_enum.py", line 7, in ?
    print "Caption: ", objItem.Caption
  File "C:\Program
Files\Python\Lib\site-packages\win32com\client\__init__.py",
line 454, in __getattr__
    raise AttributeError, "'%s' object has no attribute
'%s'" % (repr(self), attr)
AttributeError: '<win32com.gen_py.Microsoft WMI
Scripting V1.2 Library.ISWbemObjectEx instance at
0x14848208>' object has no attribute 'Caption'
--- end output ---

I have found that the objItem.Caption attribute is not
available, but I can use objItem.Properties_.Item(
'Caption' ).Value to acquire the correct result.

I am unsure how to approach this problem, but I post it
for public knowledge.  I will be happy to look into the
problem further or provide more information, but I
would need some direction to proceed.

----------------------------------------------------------------------

Comment By: Tim Johnson (tojo2000)
Date: 2007-08-16 16:46

Message:
Logged In: YES 
user_id=360594
Originator: NO

I get the same error when I try to create an SMS_CollectionMembershipRule
object using WMI.  

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2005-06-27 05:07

Message:
Logged In: YES 
user_id=14198

It looks like these interfaces are designed to be used
early-bound.  I can't find 'Caption' described in the
typelib at all.  I'm not sure how to proceed either!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1202339&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1587023 ] ActiveScript, LazyDispatchItem doesn't rename properties

[SourceForge.net <no...@so...>]

Bugs item #1587023, was opened at 2006-10-30 09:19
Message generated for change (Comment added) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587023&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: com
Group: None
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: ActiveScript, LazyDispatchItem doesn't rename properties

Initial Comment:
The problem seems to be that LazyDispatchItem doesn't
remap the
properties as DispatchItem does. If I disable the
LazyDispatchItem
generation in MakeOleRepr and always return a
DispatchItem object, the
script works as expected.

See the following thread for more information:

http://mail.python.org/pipermail/python-win32/2006-October/005174.html

----------------------------------------------------------------------

>Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 08:39

Message:
Logged In: YES 
user_id=1585378
Originator: YES

This problem only occurs when working with a typed COM Object (not
IDispatch) wrapped by LazyDispatch. This is the case when running Python
Active Scripts and executing normal scripts without the gen_py interface.

When I use such an object with a Set property, Python uses the wrong
property name (with Set) when calling typecomp.Bind.

I've found a better solution:

Index: dynamic.py
===================================================================
--- dynamic.py  (revision 36121)
+++ dynamic.py  (working copy)
@@ -377,6 +377,8 @@
               for i in ALL_INVOKE_TYPES:
                       try:
                               x,t = typecomp.Bind(attr,i)
+                               if x==0 and (attr[:3] == 'Set' or attr[:3]
== 'Get'):
+                                       x,t = typecomp.Bind(attr[3:], i) #
strip get / set
                               if x==1:        #it's a FUNCDESC
                                       r =
olerepr._AddFunc_(typeinfo,t,0)
                               elif x==2:      #it's a VARDESC



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1587023&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 11:22
Message generated for change (Comment added) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 08:31

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Yes, at least interactive makepy from pythonwin works without the int
calls (I even removed minor and major completely from selecttlb.py).

The bug doesn't appear with most typelibs, since their version numbers
aren't high enough. For me, this is the case with all the Microsoft Office
typelibs.

Note that the Microsoft office Typelib browser doesn't show the version
numbers at all. It only shows the typelib "helpstring". Maybe you should
remove the version number too?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 20:00

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks for that - at least this confirms that (a) they *should* be hex,
and (b) that even MS manages to get this wrong.  I'd prefer to simply
remove the int() calls alltogether, and then fix any code which still
assumes integers.  I've made that change locally, but I'm travelling, so
unable to fully test this until I get home.  I'd appreciate it if you could
make a similar change (ie, remove the int() calls, and the try/except block
completely) and see if anything else breaks for you.

----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-14 16:10

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Check out the following link:

http://support.microsoft.com/kb/816970



----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-14 16:05

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Not sure if there is a standard, but a simple version statement like the
following actually produces a a.0:

[
    uuid(...),
    version(10.0),
    helpstring(...)
]

library OURLIB
{
    ...

By googling around a bit there seems to be several apps using this scheme
(Corel Wordperfect 12)

Why disallow it in the first place?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 15:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 19:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-15 04:00

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks for that - at least this confirms that (a) they *should* be hex,
and (b) that even MS manages to get this wrong.  I'd prefer to simply
remove the int() calls alltogether, and then fix any code which still
assumes integers.  I've made that change locally, but I'm travelling, so
unable to fully test this until I get home.  I'd appreciate it if you could
make a similar change (ie, remove the int() calls, and the try/except block
completely) and see if anything else breaks for you.

----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 00:10

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Check out the following link:

http://support.microsoft.com/kb/816970



----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-15 00:05

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Not sure if there is a standard, but a simple version statement like the
following actually produces a a.0:

[
    uuid(...),
    version(10.0),
    helpstring(...)
]

library OURLIB
{
    ...

By googling around a bit there seems to be several apps using this scheme
(Corel Wordperfect 12)

Why disallow it in the first place?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 23:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 11:22
Message generated for change (Comment added) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-14 16:10

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Check out the following link:

http://support.microsoft.com/kb/816970



----------------------------------------------------------------------

Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-14 16:05

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Not sure if there is a standard, but a simple version statement like the
following actually produces a a.0:

[
    uuid(...),
    version(10.0),
    helpstring(...)
]

library OURLIB
{
    ...

By googling around a bit there seems to be several apps using this scheme
(Corel Wordperfect 12)

Why disallow it in the first place?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 15:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 11:22
Message generated for change (Comment added) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Johan Lindvall (j_lindvall)
Date: 2007-08-14 16:05

Message:
Logged In: YES 
user_id=1585378
Originator: YES

Not sure if there is a standard, but a simple version statement like the
following actually produces a a.0:

[
    uuid(...),
    version(10.0),
    helpstring(...)
]

library OURLIB
{
    ...

By googling around a bit there seems to be several apps using this scheme
(Corel Wordperfect 12)

Why disallow it in the first place?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 15:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 19:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2007-08-14 23:51

Message:
Logged In: YES 
user_id=14198
Originator: NO

I'd love to find some documentation that states the tlb version numbers
are hex!  Are you sure that you aren't simply creating an invalid typelib
for yourself?  Office 10, for example, doesn't use hex to the best of my
knowledge.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 11:22
Message generated for change (Settings changed) made by j_lindvall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Johan Lindvall (j_lindvall)
>Assigned to: Mark Hammond (mhammond)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1773724 ] Selecttlb doesn't handle hexadecimal version numbers

[SourceForge.net <no...@so...>]

Bugs item #1773724, was opened at 2007-08-14 11:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johan Lindvall (j_lindvall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Selecttlb doesn't handle hexadecimal version numbers

Initial Comment:
It appears Selecttlb.py for pywin32 210 doesn't handle typelibs with
hexadecimal version numbers. After updating our app to version 10.0
(a.0), we cannot use makepy anymore

The attached patch fixed the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1773724&group_id=78018