unsubscribe
···
On Wed, Oct 9, 2013 at 11:31 AM, wxpython-users@googlegroups.com wrote:
Today’s Topic Summary
- Mouse click outside of control [6 Updates]
- Displaying several thousand nodes in a HyperTreeList [5 Updates]
- Wx Glade Progress Bar Error [1 Update]
- accessing a grid [1 Update]
- wxpython unit-testing problem [3 Updates]
Mouse click outside of control
Torsten topic2k@googlemail.com Oct 08 11:20AM -0700
Did you tried event.Skip()?From the docs:
void wxEvent::Skip (bool skip = true)
This method can be used inside an event handler to control whether further
event handlers bound to this event will be called after the current one
returns.
Without Skip()mk:MSITStore:C:\Program%20Files%20(x86)\wxPython2.9%20Docs%20and%20Demos\docs\wx.chm::/classwx_event.html#a98eb20b76106f9a933c2eb3ee119f66c(or equivalently if Skip(
false) is used), the event will not be processed any more. If Skip(true) is
called, the event processing system continues searching for a further
handler function for this event, even though it has been processed already
in the current handler.
In general, it is recommended to skip all non-command events to allow the
default handling to take place. The command events are, however, normally
not skipped as usually a single command such as a button click or menu item
selection must only be processed by one handler.
Robin Dunn robin@alldunn.com Oct 08 06:21PM -0700
Alexandru Popa wrote:ComboCtrl behaves like I want in that it closes the popup list when an
outside click is made, but other buttons also get triggered if the click
was made on them. Is there a way to resend the mouse event ?
I think I would approach this a little differently. Have you tried
using the EVT_KILL_FOCUS event to trigger hiding the textctrl? That
would leave the mouse uncaptured so it continues to behave as you wish
over the other controls, and as soon as the active textctrl loses the
focus (by clicking elsewhere, or using Tab) then your handler can hide
it. Be sure to call event.Skip in the EVT_KILL_FOCUS handler so the
default handler will still be called.
–
Robin Dunn
Software Craftsman
Robin Dunn robin@alldunn.com Oct 08 06:21PM -0700
Torsten wrote:This method can be used inside an event handler to control whether
further event handlers bound to this event will be called after the
current one returns.
That won’t help when the mouse is captured. The events will always go
to the widget with the capture, and only that widget, even if the cursor
is located above another widget.
–
Robin Dunn
Software Craftsman
Alexandru Popa a.ephesos@gmail.com Oct 08 11:46PM -0700
Yes, I already handle the EVT_KILL_FOCUS , what I don't like about it isthat a click on an empty portion of one of the panels will not trigger this
event, this is what made me try the capture mouse solution as well.
Right now I’m actually thinking of a few other options:
- adding a button next to the text ctrl(only when visible), so that
after writing smth there, the user would be forced to click the button in
order to accept the new value.
- using a mix of CallLater() and EVT_LEAVE_WINDOW, so that when the
mouse exits the textctrl, EVT_LEAVE_WINDOW would trigger and activate
CallLater() which should check the mouse position after x milliseconds and
hide the textctrl if the mouse position is still outside the textctrl
rectangle. This would be a little bit more complicated, since I have to
consider multiple EVT_LEAVE_WINDOW triggers.
- a mix of the above
I’m open to further suggestions btw
!
Thanks !
On Wednesday, 9 October 2013 04:21:11 UTC+3, Robin Dunn wrote:
“Mark Weng” wenkuoweng@163.com Oct 09 10:23PM +0800
EVT_KILL_FOCUS can be tiggered when clicking on an empty portion of the panel. You can bind EVT_LEFT_DOWN to the panel and invoke SetFocusIgnoringChildren() in the handler.Mark
At 2013-10-09 14:46:49,“Alexandru Popa” a.ephesos@gmail.com wrote:
Yes, I already handle the EVT_KILL_FOCUS , what I don’t like about it is that a click on an empty portion of one of the panels will not trigger this event…
Alexandru Popa a.ephesos@gmail.com Oct 09 07:43AM -0700
I thought the event would be swallowed by one of the panel children, butyou are correct, it did get triggered and SetFocusIgnoringChildren() is a
nice touch :).
The problem is now solved, thank you for your help, and sorry for my
misguided presumptions !
On Wednesday, 9 October 2013 17:23:17 UTC+3, Mark Weng wrote:
Thierry Brizzi thierry.brizzi@gmail.com Oct 08 09:33AM -0700
I've finally written a program subclassing the way the HTL is displayed.The tree contains 2 nodes, each of them containing 20000 sub-nodes. Using
wxPython 2.8.12.1, the program prints the time for displaying horizontal
and vertical connectors. When the scrollbar is moved with the mouse to the
end of the tree, it shows that drawing horizontal connectors is
“instantaneous” whereas drawing vertical connectors is longer and longer.
Le mardi 8 octobre 2013 17:15:32 UTC+2, Thierry Brizzi a écrit :
Robin Dunn robin@alldunn.com Oct 08 06:22PM -0700
Thierry Brizzi wrote:vertical ones with the same wx.Pen. The tree becomes ugly, but all
is fine when the wx.DOT style is used. Is this a known limitation of
wxPython ?
I expect that it is an issue related to the huge vertical size of the
scrolled window’s virtual size. If you look at the contents of v_lines
you’ll see that the y values are getting up to 400k or more. I’m not
exactly sure how that would effect drawing times, but considering that
pixel positions > 32k or 64k would simply fail on Windows as recently as
Windows XP it’s not too surprising.
Unfortunately the only other approach that comes to mind is probably
much more work than it’s worth. (Reimplementing all the virtual size
aspects of the scrolled window such that only physical client area
coordinates are ever passed to the native APIs.)
–
Robin Dunn
Software Craftsman
Thierry Brizzi thierry.brizzi@gmail.com Oct 09 01:04AM -0700
I found the bottleneck : in fact some vertical connectors are drawn fromthe start of the tree to the end of the tree. As some lines are more than
300k pixels long, it explains why the DrawLineList hangs for vertical
connectors.
Le mercredi 9 octobre 2013 03:22:48 UTC+2, Robin Dunn a écrit :
Thierry Brizzi thierry.brizzi@gmail.com Oct 09 01:55AM -0700
Hopefully, low level functions of wxpython weren't involved. So, I'veupdated the original program to draw vertical connectors in a faster way
and prevent the OnPaint method to compute every times item positions
because it is already done in the OnInternalIdle method of CustomTreeCtrl.
In my mind, even if drawing thousand of nodes hangs, the OnPaint method has
reached acceptable performaces regarding the needs of my application.
So now, how can these improvements be integrated in AGW ?
Cheers.
Le mercredi 9 octobre 2013 10:04:24 UTC+2, Thierry Brizzi a écrit :
werner wbruhin@free.fr Oct 09 12:19PM +0200
Hi Thierry,On 09/10/2013 10:55, Thierry Brizzi wrote:
the OnPaint method has reached acceptable performaces regarding the
needs of my application.
So now, how can these improvements be integrated in AGW ?
A patch against latest SVN to the dev mail list
(wxpython-dev@googlegroups.com).
I think, but I am not sure, a separate pull request
(https://github.com/RobinD42/Phoenix/commits/master) to ensure this also
gets into Phoenix.
Werner
Robin Dunn robin@alldunn.com Oct 08 06:21PM -0700
kb wrote:Robin – while plotting a graph the same thing everytime, sometimes I
run into this error but sometiems i dont. Its the same with the same
parameters…
Perhaps there is a floating point rounding problem someplace that ends
up causing Update to be called with max+1.
–
Robin Dunn
Software Craftsman
Robin Dunn robin@alldunn.com Oct 08 06:19PM -0700
Larry Martell wrote:I think we’re running 2.8.9.1.
Why do I not have GUIEventLoop? Is it only in a later version?
Yep. 2.8.9.1 is over 5 years old.
–
Robin Dunn
Software Craftsman
Paul pazerp@gmail.com Oct 08 11:38AM -0700
Hi,I’m having trouble coordinating the unittests of my wxpython app. I have
two test files with essentially the same layout:
— test mod layout ---- #*
class MyApp(wx.App):
def OnInit(self): self.frame = wx.Frame(None) return Trueclass test_RunGUITests(unittest.TestCase):
def setUp(self): self.app = MyApp(redirect=False) self.frame = AppFrame(None, title='Accounter')… Run tests…
def tearDown(self): self.frame.Destroy() wx.GetApp().ExitMainLoop()I then have a file used to execute specified test modules:
# — script used to start the tests — #
if name = ‘main’
tests = {0: 'path/to/testmod1', 1: 'path/to/testmod2'} to_run = [0,1] for each in to_run: nose.run(argv=["w", "-s", testmods[each]])Both modules run with no problems If I execute them individually, (e.g. set
to_run = [1]). However if I try to run them one after the other (to_run =
[0,1]) one of the tests in the module being run in second place always
fails with the excpetion: *PyNoAppError: The wx.App object must be created
first!*
Having experimented for the last couple of hours I’m no closer to
understanding what’s going on. My hunch is that I’m not clearing up my app
objects correctly, but I can’t rule out the possibility that the problem is
something to do with the workings of nose and/or unittest. Does any one
have any ideas?
werner wbruhin@free.fr Oct 08 09:06PM +0200
Hi Paul,On 08/10/2013 20:38, Paul wrote:
Hi,
I’m having trouble coordinating the unittests of my wxpython app. I
have two test files with essentially the same layout:
Did you look at the tests in Phoenix?
The setup/teardown is done differently, see unittest\wtc.py
Werner
Paul pazerp@gmail.com Oct 08 03:07PM -0700
Hi Werner,Thanks for the tip. I updated my tearDown() to match that used in wtc.pywhich at least reassured me that I was closing the app correctly. After
having done this I was disappointed to find that I was still encountering
similar problems. I then had a more thorough look over wtc.py and noticed
that pubsub.pub was also given special treatment in unittest tearDowns. My
app uses this module in a couple of places so I updated the relevant
methods to dispose of them as per wtc.py, and all is now well.
Many thanks!
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Scott D. Lane, Ph.D.