The SourceForge shell servers are not currently allowing logins and so I can't update the website, but I wanted to let you know that wxPython 2.4.2.4 is ready for download. Since the website can't be updated yet you can't get it from the wxPython downloads page, but you can get to it if you go directly to the SourceForge project page here:
wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is implemented as a Python extension module that wraps the popular wxWindows cross platform GUI library, which is written in C++.
wxPython is a cross-platform toolkit. This means that the same program will usually run on multiple platforms without modifications. Currently supported platforms are 32-bit Microsoft Windows, most Linux or other Unix-like systems, and Macintosh OS X.
Changes in 2.4.2.4
------------------
This version is mostly a bug-fix release, but there are also a few new features:
* Use wxSTC in the demo for displaying the soucre code of the
samples.
* Added wxPython.lib.newevent from Miki Tebeka. Its usage is
demonstrated in the Threads sample in the demo.
* Updates to wxMaskedEditCtrl.
* Added wxMaskedNumCtrl.
* Added Chris Barker's FloatCanvas.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
The SourceForge shell servers are not currently allowing logins and so I
can't update the website, but I wanted to let you know that wxPython
2.4.2.4 is ready for download. Since the website can't be updated yet
you can't get it from the wxPython downloads page, but you can get to it
if you go directly to the SourceForge project page here:
wxPython is a GUI toolkit for the Python programming language. It allows
Python programmers to create programs with a robust, highly functional
graphical user interface, simply and easily. It is implemented as a
Python extension module that wraps the popular wxWindows cross platform
GUI library, which is written in C++.
wxPython is a cross-platform toolkit. This means that the same program
will usually run on multiple platforms without modifications. Currently
supported platforms are 32-bit Microsoft Windows, most Linux or other
Unix-like systems, and Macintosh OS X.
Changes in 2.4.2.4
------------------
This version is mostly a bug-fix release, but there are also a few new
features:
* Use wxSTC in the demo for displaying the soucre code of the
samples.
* Added wxPython.lib.newevent from Miki Tebeka. Its usage is
demonstrated in the Threads sample in the demo.
* Updates to wxMaskedEditCtrl.
* Added wxMaskedNumCtrl.
* Added Chris Barker's FloatCanvas.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Some time ago I had this problem with the wrong positioning in the
wxTreeListCtrl with a HitTest. In the following code I display a popup
menu with a right click on the wxTreeListCtrl.
def OnRightClick(self, event):
if hasattr(self,"P_UpMenu"):
self.PopupMenuXY(self.P_UpMenu.popupmnu, self.x, self.y)
event.Skip()
------ snip --------------
I anxiously awaited the new release and installed it directly......
However, it looks as though the problem is not solved. The menu still
pops up one line above the actual click.
Some time ago I had this problem with the wrong positioning in the
wxTreeListCtrl with a HitTest. In the following code I display a popup
menu with a right click on the wxTreeListCtrl.
Sorry, I had a patch from Alberto that I thought had fixed this, but I didn't really pay attention to what it was changing. I just went back and reviewed it was actually for another problem and this is what he said:
"""
As for the "off-by-one" bug, actually I'm not sure it's a bug at all. Here's my point: the coordinates are correctly translated in wxTreeListCtrl::HitTest to be relative to the main window... the fact that they seem to be wrong is because they are probably passed as already translated....
"""
And that is true. The point you get from event.GetPosition is relative to the subwindow that shows the items of the treelist (the other subwindow is the header) but the HitTest method expects to get coordinants relative to the main treelist window, not the subwindow. So to get the right item with HitTest you need to convert the position from being relative to the subwindow into being relative to the outer window. Here is some code I've added to the demo to show how to do this.
def OnRightUp(self, evt):
# convert the position from being relative to the subwindow to
# being relative to the outer treelist window.
pos = evt.GetPosition()
pos = self.tree.GetMainWindow().ClientToScreen(pos)
pos = self.tree.ScreenToClient(pos)
item, flags, col = self.tree.HitTest(pos)
if item:
print flags, col, self.tree.GetItemText(item, col)
···
On Thu, 2003-10-02 at 18:37, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks, it was really a pain, so I'll give it a try with your
suggestion....
Regards,
Dick
···
On Fri, 2003-10-03 at 20:52, Robin Dunn wrote:
"""
As for the "off-by-one" bug, actually I'm not sure it's a bug at all.
Here's my point: the coordinates are correctly translated in
wxTreeListCtrl::HitTest to be relative to the main window... the fact
that they seem to be wrong is because they are probably passed as
already translated....
"""
EVT_RIGHT_UP(self.tree.GetMainWindow(), self.OnRightUp)
def OnRightUp(self, evt):
# convert the position from being relative to the subwindow to
# being relative to the outer treelist window.
pos = evt.GetPosition()
pos = self.tree.GetMainWindow().ClientToScreen(pos)
pos = self.tree.ScreenToClient(pos)
item, flags, col = self.tree.HitTest(pos)
if item:
print flags, col, self.tree.GetItemText(item, col)