On Wed, Apr 13, 2011 at 11:55 PM, Mark Hammond <skippy.hamm...@gmail.com>wrote:
> Yeah - this is a bug in the general DWORD handling in SWIG generated files. > I'm not sure how to tell SWIG to use a different format char, but I have > managed to work around it in other ways which is good for the general case. > > However, in this case specifically, it doesn't seem to work as intended. > After fixing it, the Event Viewer shows the event ID is actually 18002 - > which is 0xc0004652 with the 2 most significant bits reset to zero. Digging > deeper, the docs at > http://msdn.microsoft.com/en-us/library/aa363651%28v=vs.85%29.aspx imply > those 2 bits are used to record the severity of the message. It appears the > function will mask out those bits according to the other params passed to > ReportEvent, meaning you can't wind up with such an event ID in the event > viewer anyway... > > But this consideration is specific to ReportEvent - so the next pywin32 > build will allow DWORD params in SWIG wrappers to pass such integers without > error - but it seems that wont actually help your problem. > > I'm logging events to the event log on behalf of another client. I've tried arguing this point with them, but they insist that I must use the full 32-bit event id. Something to do with how they generate their message catalogs. In any case, this snippet of python code seems to work around the problem: if id & 0x80000000: id = -0x80000000 | id ReportEvent(source, id, etc) Best Regards, --Chris
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32