gmane.comp.python.wxpython

Mouse middle button has strange effect in grids

Stéphane Larouche — 2012-05-24T22:25:52

The middle button seems to have a strange effect in grids. In particular, if I
hold it down it creates a visual selection of cells, like a range selection, but
that does not trigger a EVT_GRID_RANGE_SELECT event.

What I would like to do is that my grid completely ignores all click events on
the middle button. I have tried to catch EVT_MIDDLE_DOWN, EVT_MIDDLE_UP,
EVT_MIDDLE_DCLICK events. If I bind them to the grid, using
my_grid.Bind(EVT_MIDDLE_DOWN, my_event_handler), for example, I do capture some
events, but not all of them. I have not been able to figure out the logic behind
what events are captured and what events are not. If I bind them to the grid
window, using my_grid.GetGridWindow().Bind(EVT_MIDDLE_DOWN, my_event_handler),
for example, I do catch all middle button events, but even if I don't propagate
them (not using event.Skip()), a visual selection is still created.

Does anyone know a solution to that problem?

Thank you for your help.

Stéphane

Re: Re: Setting Focus to Grid when Clicking on Grid Label

Jay — 2012-05-24T20:27:26

I know. I was just wondering if this is a bug, or desired behavior. See my 
previous post 
https://groups.google.com/d/msg/wxpython-users/h87HDZVivtw/YuvuRt4fedsJ, 
for why I thought it might be a bug.

On Thursday, May 24, 2012 3:44:55 PM UTC-2:30, Robin Dunn wrote:

Re: Setting Focus to Grid when Clicking on Grid Label

Jay — 2012-05-24T20:22:39

I click on row labels to select rows, then handle keystrokes to operate on 
these rows, e.g. ctrl-c to copy a row and ctrl-v to paste it. Users might 
never click in a cell, but because the row is highlighted/selected by 
clicking on the label, they will try to issue keystroke commands such as 
ctrl-c, and these would fail, or worse muck up another control's value.

I know how to work around it, as commented out in the code. (thanks for the 
suggestion anyway). I just got caught me off guard when the Grid didn't set 
the focus automatically, so I was wondering if this was a bug or not.

On Thursday, May 24, 2012 3:19:34 PM UTC-2:30, Mike Driscoll wrote:

Re: dc.DrawText performance issues

Kevin Ollivier — 2012-05-24T18:49:00

Hi Robin, Jonathan,

On May 24, 2012, at 11:14 AM, Robin Dunn wrote:


Another thing that would help is to call RefreshRect() instead of Refresh, passing in the rect of whatever part of the canvas that needs redrawn, and clipping your drawing to it. (You can get the rect via window.GetUpdateRegion().GetBox()) Clipping does indeed affect performance quite considerably, because the calls to DrawText and such will do no drawing if they're outside the clipping rect.

Also, you can make sure to call RefreshRect only if something in the canvas needs redrawn, e.g. when the .hover or .info state of one of the links changes. This would probably significantly reduce the number of paint events you're sending. 

Regards,

Kevin

Re: Re: Setting Focus to Grid when Clicking on Grid Label

Robin Dunn — 2012-05-24T18:14:55

You already have the solution commented out in the code.  Explicitly set 
the focus to the grid when you get EVT_GRID_LABEL_LEFT_CLICK events. 
That handler should also call event.Skip() however so the grid can still 
process that event itself.

Re: Re: textctrl multiline errors on linux

Robin Dunn — 2012-05-24T18:14:36

Yes, but XRC should be applying the style when it creates the widget. 
Is it not doing that?

Re: Re: dc.DrawText performance issues

Robin Dunn — 2012-05-24T18:14:27

Also consider a design where only that which is changing is actually 
drawn, and cache as much of the rest of it as you can in one or more 
bitmaps.

For example if your window's content fits this model you could have a 
bitmap for the  "background" (grid lines, labels, etc) for things that 
don't change very often if at all.  Then another bitmap that is the 
background plus the current content.  When the current content needs to 
change you don't have to redraw the entire background, just draw the 
background bitmap into the content bitmap via a wx.MemoryDC and then 
redraw the content on top of that.  Then for immediate changes, such as 
in mouse events you can either manipulate just the section of the 
content bitmap that is changing or simply draw on top of it and then 
adjust the actual content bitmap in idle time or something.  When paint 
events happen you just draw the content bitmap and you are done, so they 
are very efficient.

Re: Setting Focus to Grid when Clicking on Grid Label

Mike Driscoll — 2012-05-24T17:49:34


On Thursday, May 24, 2012 10:43:00 AM UTC-5, Jay wrote:
Um, why are you clicking on a label? I clicked on a cell and it worked just 
fine. Clicking on a label won't work. I suppose you could catch the focus 
event and transfer the focus to the first cell if that's what you want. 

- Mike

Re: Re: dc.DrawText performance issues

Chris Barker — 2012-05-24T17:29:31

I've found that calling DrawText hundreds of times is usually pretty
fast -- thousands not so much.

On Thu, May 24, 2012 at 10:09 AM, Jonathan <jonauncensored< at >gmail.com> wrote:

re-drawing eveyting on mouse_move is pretty sketcy -- you really need
blzingly fast drawing for that to feel smooth (liek OPneGL..).

Is something changing with every mouse move? what?

Is the common case, there is a little bit that might change on a
mouse_move, like a highlight of the object the mouse is over. In this
case, I'd look at using an overlay to draw just that.

or double-buffer and then draw the changing bit yourself (really jsut
a hand-done overlay)

see:

http://wiki.wxpython.org/DoubleBufferedDrawing

for more about that.

(note: that page was written before wxOverlay existed)


HTH,
 -Chris



probably , yes.

you might want to take a look at wx.lib.floatcanvas -- it does a lot
of this for you.

see the demo in:

http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/ProcessDiagram.py?view=markup

for an example that might be close to what you need to do.

in any case, FloatCanvas itself may give you ideas about how to handle
double buffering, etc.

HTH,
  -Chris

Re: Momentary button

Chris Barker — 2012-05-24T17:20:43

THis may well be platfrom-dependent behaviour. As wx uses the platfrom
native widgets, it's really only reliable to use a button like a
button is usually used.

I"d take a look at wx.lib.button.GenButton (and others in
wx.lib.buttons) -- that should be easier to customize.

-Chris

Momentary button

Greg - ZL3IX — 2012-05-24T09:11:56

Am I right in thinking that wxButton cannot bind in a momentary fashion,
ie trigger an event when the mouse button is pressed (on the button),
and another when it is released?  I have tried to bind it using
wx.EVT_LEFT_DOWN, but the event is not triggered.  I get the feeling
that the only event that can be detected is that the mouse button has
been clicked and released.  Is that correct?

If that is so (surprising) I guess I have to detect mouse hover over the
button AND left button down.  Seems a little clumsy maybe?

Greg

Re: dc.DrawText performance issues

Jonathan — 2012-05-24T17:09:13

You're correct, this is being called under mouse operations. I've seen
the clipping region functions while browsing the documentation, but
I've read some comments talking about drawing performance that said
adding this wouldn't help much. Perhaps it would be better to isolate
this code into a separate drawing function that is only called when
the graph is phyically modified (ie a node is moved), although then I
need to deal with the text not being drawn over when refreshing the
graph.

On May 24, 12:42 pm, Tim Roberts <t...< at >probo.com> wrote:

Re: Re: dc.DrawText performance issues

Tim Roberts — 2012-05-24T16:42:51

No, there is no "limit".  How often is this being called?  The mention
of "link.hover" and "link.info" makes me wonder if you are calling this
during mouse move operations, hundreds or thousands of times a second. 
Is that the case?

You could save a little time by creating the wx.Pen and wx.Brush ahead
of time and caching them.

Re: Setting Focus to Grid when Clicking on Grid Label

Jay — 2012-05-24T15:43:00

I modified the code, but still get the same result: click on a grid label, 
press any character key, and the text control handles that character event, 
not the Grid.

On Thursday, May 24, 2012 11:10:18 AM UTC-2:30, Mike Driscoll wrote:

Re: Setting Focus to Grid when Clicking on Grid Label

Mike Driscoll — 2012-05-24T13:40:18


On Thursday, May 24, 2012 8:28:58 AM UTC-5, Jay wrote:

Well, you disabled editing of the Grid, so I'm not sure what you expected 
would happen. You certainly can't edit something that you've disabled.  If 
you pass True to self.grid1.EnableEditing, then it works the way it ought 
to.

- Mike

Re: dc.DrawText performance issues

Jonathan — 2012-05-24T13:37:43

I should note the problem lies in dc.DrawText. Remove these calls and
everything runs smoothly. Is there a limit to how many times
dc.DrawText should be called per OnPaint?

On May 23, 12:42 pm, Jonathan <jonauncenso...< at >gmail.com> wrote:

Setting Focus to Grid when Clicking on Grid Label

Jay — 2012-05-24T13:28:58

Hi wxPython users:

I'm not sure if this is a feature, or a bug. I have a Grid control and 
TextCtrl on the same panel. I expect the focus to shift to the Grid control 
when the user clicks on a row or column label, but it does not. Keyboard 
operations are still directed to the last active control, which is a 
TextCtrl in my case. As a result, a Grid row is highlighted, but keystrokes 
that might be necessary to operate on the Grid (e.g. CTRL-C to copy a row) 
are directed to the TextCtrl. The user does not expect this and is shocked 
to see the text control changed when they thought they were working on the 
Grid control.

This issue has been reported before on this group: 
https://groups.google.com/forum/?fromgroups#!searchin/wxpython-users/grid$20set$20focus/wxpython-users/QL0lKmY2LoM/mM8zkG-LOQMJ

I have attached the code from the aforementioned post, modified just 
slightly, to reproduce the problem. Run App1.py and note the TextCtrl has 
the focus. Click a grid row label and note the TextCtrl still has focus. 
Now press an alpha-numeric key and observe the character is inserted in the 
TextCtrl.

To work around the "problem", I call Grid.SetFocus() in mouse click event 
handlers. To see this, uncomment the code beneath the UNCOMMENT TO FIX 
comment.

Is this a feature or a bug?

Environment: Windows XP, wxPython 2.8.12.1, Python 2.7.2 (default, Jun 12 
2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32

Thanks.

dc.DrawText performance issues

Jonathan — 2012-05-23T16:42:02

I'm drawing a network graph with wx.PaintDC. For each link in my graph
I draw the source and destination port numbers on a box over the link
30pixels away from the endpoints. This works fine when I'm only
drawing the ports for a single link, but when I draw the ports for all
of the links (I'm testing on tree with 12 links) I get a major
performance hit. What strategies can I use to get my graph back to a
usable state?

    # If extra info is desired draw ports
    if link.hover or link.info:
        dc.SetPen(wx.Pen(wx.Colour(58,58,58), 1))
        dc.SetBrush(wx.Brush(wx.Colour(255,255,255)))

        # Draw srcport
        sx, sy = gmath.PointOnLine(dstpos, srcpos, -30)
        ss = str(link.srcport)
        sw, sh = dc.GetTextExtent(ss)
        dc.DrawRectangle(sx-3, sy-3, sw+6, sh+6)
        # Draw dstport
        dx, dy = gmath.PointOnLine(srcpos, dstpos, -30)
        ds = str(link.dstport)
        dw, dh = dc.GetTextExtent(ds)
        dc.DrawRectangle(dx-3, dy-3, dw+6, dh+6)

        dc.DrawText(ss, sx, sy)
        dc.DrawText(ds, dx, dy)

Paste and delete bug in wx.lib.intctrl.IntCtrl?

Jay — 2012-05-23T21:17:36

Two issues:

1. If I paste non-numeric text, such as "max" using the context menu Paste, 
the non-numeric text is inserted. I think this is incorrect behavior, but 
worse an exception is raised, as follows:

    Traceback (most recent call last):
      File 
"C:\Programs\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\intctrl.py", 
line 474, in OnText
        value = self.GetValue()
      File 
"C:\Programs\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\intctrl.py", 
line 490, in GetValue
        return self._fromGUI( wx.TextCtrl.GetValue(self) )
      File 
"C:\Programs\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\intctrl.py", 
line 782, in _fromGUI
        return long( value )
    ValueError: invalid literal for long() with base 10: '0max'

2. If I cut or delete the control's value using the context menu Cut or 
Delete, an empty string value is left in the control. This is an error 
because the IntCtrl option allow_none is False.

To reproduce, run the wxPython Demo from the command line and launch the 
IntCtrl demo. Now perform the operations enumerated above.

Some quick debugging shows that the "overridden" methods Cut() and Paste() 
are not called, but I'm thinking the original author expected them to be.

This seems like an issue to me. Anyone care to confirm if this is bug? Any 
suggestions for a work around?

Environment:
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] 
on win32
Windows XP
wxPython 2.8.12.1

Re: Import Error: No module named wordwrap

llanitedave — 2012-05-22T22:22:57

Got it!  From your link, I simply added

*import wxversion*
*wxversion.select("2.8")*

Above the import wx command, and everything is working correctly now!

I'm still wondering why it took the Ubuntu 12.04 upgrade to throw it all 
out of kilter, but I'll definitely be getting rid of wx-2.6.

Thank you very much, Mike.

BTW, I have already gotten some valuable tips from your blog, too.

Dave




On Tuesday, May 22, 2012 2:40:42 PM UTC-7, Mike Driscoll wrote:

Re: Import Error: No module named wordwrap

Mike Driscoll — 2012-05-22T21:40:42


On Tuesday, May 22, 2012 4:28:14 PM UTC-5, llanitedave wrote:
Ugh. wxPython 2.6 is super old. I would try to uninstall it and then maybe 
Open Stereo will pick up the right one. If not, you may need to reinstall 
the newer 2.8 again. You can also wxversion: 
http://wiki.wxpython.org/MultiVersionInstalls#How_do_I_use_wxversion.3F