This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author robind
Recipients loewis, robind
Date 2009-04-27.16:30:57
SpamBayes Score 2.322539e-07
Marked as misclassified No
Message-id <1240849872.75.0.770862813632.issue5019@psf.upfronthosting.co.za>
In-reply-to
Content
Update:  I finally worked out what needed to be done for wxPython and
while simply changing Python's manifest would have been immensely easier
what I have does seem to work well so I thought I should give some info
here for posterity.

I went back and experimented again with creating an Activation Context
in the C code that loads a proper manifest, and found that it seemed to
work in some situations and not in others.  I eventually narrowed it
down to the fact that any UI object created from within a timer event
handler would always use the processes' default context instead of any
other activated context.  (In this case that means that it would always
use the manifest embedded in python.exe instead of any other manifest,
programatically loaded or otherwise.)  Since the main frame in
wxPython's demo is loaded via a timer (when the splash screen times out)
then this made it appear that all of my prior experiments had failed,
when in fact some of them probably at least partially succeeded.

After further experimentation I found that switching wxTimer to use a
hidden window for catching and processing timer events, instead of using
a TimerProc callback, solves the problem with the new activation context
being ignored.  So I guess we can call this a microsoft bug and move on.

More details are in this thread:
http://lists.wxwidgets.org/pipermail/wxpython-dev/2009-April/004199.html
History
Date User Action Args
2009-04-27 16:31:12robindsetrecipients: + robind, loewis
2009-04-27 16:31:12robindsetmessageid: <1240849872.75.0.770862813632.issue5019@psf.upfronthosting.co.za>
2009-04-27 16:31:00robindlinkissue5019 messages
2009-04-27 16:30:57robindcreate