Folks,
I had ported a program of mine, back in version 2.5.1.5 I believe, to use the new argument format where you pass point and size tuples to define the rects in many wx.DC calls.
In the process of porting to 2.5.2.8, I forgot to fix a call to DC.Blit, which now has the prototype like it used to:
when I should have called dc.BlitPointSize.
The bad thing is that this call did not generate an exception, and I had some weird problems far away in my code, as if the resulting Blit wrote all over some other structures.
I don't know if I should try to learn how to file a bug report on this or if Robin will look into this....
Folks,
I had ported a program of mine, back in version 2.5.1.5 I believe, to use the new argument format where you pass point and size tuples to define the rects in many wx.DC calls.
In the process of porting to 2.5.2.8, I forgot to fix a call to DC.Blit, which now has the prototype like it used to:
when I should have called dc.BlitPointSize.
The bad thing is that this call did not generate an exception, and I had some weird problems far away in my code, as if the resulting Blit wrote all over some other structures.
I get this with 2.5.2.8:
>>> dc.Blit(r1.GetPosition(), r1.GetSize(), sdc, r2.GetPosition())
Traceback (most recent call last):
File "<input>", line 1, in ?
File "/usr/lib/python2.3/site-packages/wx/_gdi.py", line 2808, in Blit
return _gdi_.DC_Blit(*args, **kwargs)
TypeError: DC_Blit() takes at least 8 arguments (5 given)
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Folks,
I had ported a program of mine, back in version 2.5.1.5 I believe, to use the new argument format where you pass point and size tuples to define the rects in many wx.DC calls.
In the process of porting to 2.5.2.8, I forgot to fix a call to DC.Blit, which now has the prototype like it used to:
when I should have called dc.BlitPointSize.
The bad thing is that this call did not generate an exception, and I had some weird problems far away in my code, as if the resulting Blit wrote all over some other structures.
I get this with 2.5.2.8:
>>> dc.Blit(r1.GetPosition(), r1.GetSize(), sdc, r2.GetPosition())
Traceback (most recent call last):
File "<input>", line 1, in ?
File "/usr/lib/python2.3/site-packages/wx/_gdi.py", line 2808, in Blit
return _gdi_.DC_Blit(*args, **kwargs)
TypeError: DC_Blit() takes at least 8 arguments (5 given)
Thanks, Robin, and sorry to have wasted your time. After looking at it some more, I realized that my call to dc.Blit was in my EVT_PAINT handler. Exceptions there don't make it to my console (nor do print statements). (I'm on win2K) I recall that callbacks often run under somebody elses process, and who knows where the stdout of that process is going. How do people debug their OnPaint routines?
Thanks, Robin, and sorry to have wasted your time. After looking at it some more, I realized that my call to dc.Blit was in my EVT_PAINT handler. Exceptions there don't make it to my console (nor do print statements). (I'm on win2K) I recall that callbacks often run under somebody elses process, and who knows where the stdout of that process is going. How do people debug their OnPaint routines?
If you set the redirect flag in the wx.App contstructor to False and then run the app from a Windows console window with python.exe then you should see the all prints to stdout or stderr no matter where they come from. I also see prints from OnPaint in the popup stdout/stderr window too, but I suppose that there could be situations when it may be blocked.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!