I have an app that I built years ago and have not changed in a while.
It has been running smoothly through various iterations of wxPython.
The app is centered around the StyledTextCtrl. I recently updated to
2.8.11.0 and the control seems to go haywire. A number of things are
broken for instance:
When I select text with the mouse or keyboard the control deletes it
immediately.
When I try to navigate with the keys through the text it is very
difficult to move the cursor. I have to hold down the arrow keys to
get it to move.
When I scroll the screen with the scroll arrows the page scrolls but
when I release the buttons the view jumps back to the top of the
screen.
The column count for the control continually increments whether I
input anything or not.
Hooking up a debugger I was able to observe that a stream of
OnUpdateUI events is being pumped to the control without me providing
any input. I am not able to tell where they are originating from as
the stack shows only the message pump.
At first I thought this problem must be as result of a change in the
control's behavior. I opened up the wxpython demos and went the the
styledtextctrl demos to see if I could learn anything about the
changes or replicate the problem. To my surprise the exact same
behavior was manifest in the demo. I then opened up Editra to see if
it exhibits the same behavior and sure enough it was doing the same
thing. I then thought the problem must be with my installation. I
reinstalled py 2.7 and wxpython 2.8.11.0 64bit. That didn't change
things . I then tried py 2.6 64bit and the corresponding wxpython
2.8.11.0 and that didn't work either. I then tried the 32bit flavors
of each and they misbehaved also. So I am at a complete loss. If
someone could run the demos or Editra and tell me if they see the same
behavior I would appreciate it. Any insights would be most helpful.
I am running windows 7 ultimate 64bit with all the latest updates. I
currently have installed Py 2.7 amd64 and wxPython 2.8.11.0 amd64
unicode.
At first I thought this problem must be as result of a change in the
control's behavior. I opened up the wxpython demos and went the the
styledtextctrl demos to see if I could learn anything about the
changes or replicate the problem. To my surprise the exact same
behavior was manifest in the demo. I then opened up Editra to see if
it exhibits the same behavior and sure enough it was doing the same
thing. I then thought the problem must be with my installation. I
reinstalled py 2.7 and wxpython 2.8.11.0 64bit. That didn't change
things . I then tried py 2.6 64bit and the corresponding wxpython
2.8.11.0 and that didn't work either. I then tried the 32bit flavors
of each and they misbehaved also. So I am at a complete loss. If
someone could run the demos or Editra and tell me if they see the same
behavior I would appreciate it. Any insights would be most helpful.
On my windows 7 32 bit machine I do not see any of these problems. Have you tried with other 2.8 releases prior to 2.8.11?
I have also tried 2.8.9.2 and 2.8.10.0 in both 32 bit and 64bit
flavors. None of these seem to work. I have also tried running under
xp mode and the problem goes away when I do this.
···
On Oct 12, 7:58 pm, Cody Precord <codyprec...@gmail.com> wrote:
Hello,
On Oct 12, 2010, at 6:35 PM, ben wrote:
> At first I thought this problem must be as result of a change in the
> control's behavior. I opened up the wxpython demos and went the the
> styledtextctrl demos to see if I could learn anything about the
> changes or replicate the problem. To my surprise the exact same
> behavior was manifest in the demo. I then opened up Editra to see if
> it exhibits the same behavior and sure enough it was doing the same
> thing. I then thought the problem must be with my installation. I
> reinstalled py 2.7 and wxpython 2.8.11.0 64bit. That didn't change
> things . I then tried py 2.6 64bit and the corresponding wxpython
> 2.8.11.0 and that didn't work either. I then tried the 32bit flavors
> of each and they misbehaved also. So I am at a complete loss. If
> someone could run the demos or Editra and tell me if they see the same
> behavior I would appreciate it. Any insights would be most helpful.
On my windows 7 32 bit machine I do not see any of these problems.
Have you tried with other 2.8 releases prior to 2.8.11?
I did another test this morning. I loaded up 32bit scintilla versions
1.73 (wx2.8) and 2.03(wx2.9) to see if the problem exists in the
native control but they both seem to work.
···
On Oct 12, 7:58 pm, Cody Precord <codyprec...@gmail.com> wrote:
Hello,
On Oct 12, 2010, at 6:35 PM, ben wrote:
> At first I thought this problem must be as result of a change in the
> control's behavior. I opened up the wxpython demos and went the the
> styledtextctrl demos to see if I could learn anything about the
> changes or replicate the problem. To my surprise the exact same
> behavior was manifest in the demo. I then opened up Editra to see if
> it exhibits the same behavior and sure enough it was doing the same
> thing. I then thought the problem must be with my installation. I
> reinstalled py 2.7 and wxpython 2.8.11.0 64bit. That didn't change
> things . I then tried py 2.6 64bit and the corresponding wxpython
> 2.8.11.0 and that didn't work either. I then tried the 32bit flavors
> of each and they misbehaved also. So I am at a complete loss. If
> someone could run the demos or Editra and tell me if they see the same
> behavior I would appreciate it. Any insights would be most helpful.
On my windows 7 32 bit machine I do not see any of these problems.
Have you tried with other 2.8 releases prior to 2.8.11?
One other test result. I ran python 2.7 in vista sp2 compatibility
mode and then ran my app, the demos, and editra. That also corrects
the problem.
···
On Oct 13, 7:54 am, ben <ben.k...@gmail.com> wrote:
I did another test this morning. I loaded up 32bit scintilla versions
1.73 (wx2.8) and 2.03(wx2.9) to see if the problem exists in the
native control but they both seem to work.
On Oct 12, 7:58 pm, Cody Precord <codyprec...@gmail.com> wrote:
> Hello,
> On Oct 12, 2010, at 6:35 PM, ben wrote:
> > At first I thought this problem must be as result of a change in the
> > control's behavior. I opened up the wxpython demos and went the the
> > styledtextctrl demos to see if I could learn anything about the
> > changes or replicate the problem. To my surprise the exact same
> > behavior was manifest in the demo. I then opened up Editra to see if
> > it exhibits the same behavior and sure enough it was doing the same
> > thing. I then thought the problem must be with my installation. I
> > reinstalled py 2.7 and wxpython 2.8.11.0 64bit. That didn't change
> > things . I then tried py 2.6 64bit and the corresponding wxpython
> > 2.8.11.0 and that didn't work either. I then tried the 32bit flavors
> > of each and they misbehaved also. So I am at a complete loss. If
> > someone could run the demos or Editra and tell me if they see the same
> > behavior I would appreciate it. Any insights would be most helpful.
> On my windows 7 32 bit machine I do not see any of these problems.
> Have you tried with other 2.8 releases prior to 2.8.11?
If possible could you also please test both 32-bit and 64-bit wxPython on a different Win7-64 PC, preferably a recent install. From what you've reported so far it seems that the problem is more likely something specific to your PC, and testing on another Win7-64 machine could confirm that. The only Win7-64 environment I currently have access to is a virtual machine, (and it's actually still running the RC build, not the final release,) but wxSTC samples work fine there.
···
On 10/13/10 5:07 AM, ben wrote:
One other test result. I ran python 2.7 in vista sp2 compatibility
mode and then ran my app, the demos, and editra. That also corrects
the problem.
On Oct 13, 7:54 am, ben<ben.k...@gmail.com> wrote:
I did another test this morning. I loaded up 32bit scintilla versions
1.73 (wx2.8) and 2.03(wx2.9) to see if the problem exists in the
native control but they both seem to work.
Sorry that took so long. I had to find somebody with x64 willing to
let me experiment. Your instincts were correct. I tried it on another
Windows 7 64bit install with all the latest patches and it worked
fine. I tested 2.8.9.2, 2.8.10.0, and 2.8.11.0 each with the most
recent python version supported in both 32bit and 64bit flavors all
worked. I wonder what it is that is different on my development
machine? I do have quite a few dev tools on this machine. MS Visual
Studio 2010 might be the culprit although I made sure to take all
references to its libraries out of the path. Running depends on both
machines didn't reveal anything of note though. I have also installed/
reinstalled various python/wxPython versions through out this
machine's lifetime. I will try rebuilding the machine and see if the
problem repeats itself. Thanks to both of you for the quick response.
···
On Oct 13, 1:37 pm, Robin Dunn <ro...@alldunn.com> wrote:
On 10/13/10 5:07 AM, ben wrote:
> One other test result. I ran python 2.7 in vista sp2 compatibility
> mode and then ran my app, the demos, and editra. That also corrects
> the problem.
> On Oct 13, 7:54 am, ben<ben.k...@gmail.com> wrote:
>> I did another test this morning. I loaded up 32bit scintilla versions
>> 1.73 (wx2.8) and 2.03(wx2.9) to see if the problem exists in the
>> native control but they both seem to work.
If possible could you also please test both 32-bit and 64-bit wxPython
on a different Win7-64 PC, preferably a recent install. From what
you've reported so far it seems that the problem is more likely
something specific to your PC, and testing on another Win7-64 machine
could confirm that. The only Win7-64 environment I currently have
access to is a virtual machine, (and it's actually still running the RC
build, not the final release,) but wxSTC samples work fine there.
--
Robin Dunn
Software Craftsmanhttp://wxPython.org
Sorry that took so long. I had to find somebody with x64 willing to
let me experiment. Your instincts were correct. I tried it on another
Windows 7 64bit install with all the latest patches and it worked
fine. I tested 2.8.9.2, 2.8.10.0, and 2.8.11.0 each with the most
recent python version supported in both 32bit and 64bit flavors all
worked. I wonder what it is that is different on my development
machine? I do have quite a few dev tools on this machine. MS Visual
Studio 2010 might be the culprit although I made sure to take all
references to its libraries out of the path. Running depends on both
machines didn't reveal anything of note though. I have also installed/
reinstalled various python/wxPython versions through out this
machine's lifetime. I will try rebuilding the machine and see if the
problem repeats itself. Thanks to both of you for the quick response.
Not to try and steer off topic but this has been a bit of a curiosity
of mine as well for awhile when working on my Windows machine.
It seems that all of my wxPython applications run noticeably slower,
especially for things like raising and lower the window from the task
bar while I have Visual Studio running.
Is it possible that since wxPython uses a debug build of wxWidgets,
that Visual Studio may be instrumenting the dll's in some way or
hooking into some debug hooks that are in the dlls? This is mostly
just a hypothetical guess as I haven't had any time to do some
investigation on this.
Cody
···
On Thu, Oct 14, 2010 at 11:31 AM, ben <ben.kank@gmail.com> wrote:
The wxPython release binaries are more of a release build than a debug build as far as the platform is concerned. It uses the non-debug runtime DLLs and also excludes calls to some debugging assist function from the wx code. The only real difference from a full release-mode binary AFAIK is that __WXDEBUG__ is defined so we get the assertions turned on, although I could easily be missing something else...
···
On 10/14/10 9:43 AM, Cody Precord wrote:
It seems that all of my wxPython applications run noticeably slower,
especially for things like raising and lower the window from the task
bar while I have Visual Studio running.
Is it possible that since wxPython uses a debug build of wxWidgets,
that Visual Studio may be instrumenting the dll's in some way or
hooking into some debug hooks that are in the dlls? This is mostly
just a hypothetical guess as I haven't had any time to do some
investigation on this.