Forcing wx.grid to draw

I started using wxPython very recently, and I've been very impressed by
how easy it is to put together a working application in wxPython.

Unfortunately, I've run into my first sticking point, and I'm hoping someone
on the list can help me out.

My application does the following in sequence:
(1) displays a wx.grid in a wx.flatnotebook page,
(2) performs some computationally intensive operations, and
(3) displays another grid in a new notebook page.

Is there a way to force the first grid to display before step (2) starts
running?

yes -- but how your code is structured makes all the difference.

Would putting step (2) in a separate thread help?

That would help if you want the GUI to be responsive while the
computation is going on -- if you jsut want them to have somethign to
look at, that shouldn't be required.

Regardless of whether the application is multithreaded, I would think that I
could at least force the first grid to display before step (2) starts
chugging away. I've put a lot of research into this, and no matter what I
try, both grids display at once in their separate notebook pages, after a
long delay caused by step (2). For example I've tried to call the first
grid's ForceRefresh() method before step (2), but that doesn't help.

I'm not sure if this matters, but the steps above are all within the same
event handler.

That may the problem, yes. event handlers are blocking -- no other
event,s no other code will run until the handler is completed.

You *may* be able to call:

the_grid.Refresh()
the_grid.Update()

before the computation (Update() means draw this now) (assuming you've
already called Grid.Show()

But it would probably be more robust if you didn't put then all in teh
same handler. An easy way to do it would be to have you handler do:

#create the first grid.
wx.CallAfter(the_function_to_do_the_computation)

At the end of the_function_to_do_the_computation, put in a call to
create the second grid (I presume it needs data form the computation
to do its thing...

if that doesn't do it-- we'll need to see code:

http://wiki.wxpython.org/MakingSampleApps

-Chris

···

On Tue, Jun 5, 2012 at 10:57 AM, Nicholas Montpetit <n.d.montpetit@gmail.com> wrote:

Let me know if any other details about the program would be relevant.

Thanks so much for your help!

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Chris, thanks so much for your help! Using the Update() method worked. Now time to bring in multithreading to make the app more responsive.

One of the most challenging aspects of using wxPython so far has been trying to figure out when and where to use Refresh/ForceRefresh/Update/Repaint etc.

Thanks again for your help!

-Nick

Chris, thanks so much for your help! Using the Update() method worked.

great.

Now time to bring in multithreading to make the app more responsive.

be sure to look at:

http://wiki.wxpython.org/LongRunningTasks

if you haven't already.

One of the most challenging aspects of using wxPython so far has been trying
to figure out when and where to use Refresh/ForceRefresh/Update/Repaint etc.

I find I don't need them often -- I think the trick is to be more
event-driven -- i.e. don't put all that in one event handler.

wx.CallAfter is a really handy way to throw something on the event
stack, so it's easy to keep separate things separate.

-Chris

···

On Tue, Jun 5, 2012 at 12:08 PM, Nicholas Montpetit <n.d.montpetit@gmail.com> wrote:

Thanks again for your help!
-Nick

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Now time to bring in multithreading to make the app more responsive.

be sure to look at:

http://wiki.wxpython.org/LongRunningTasks

if you haven’t already.

+1

One of the most challenging aspects of using wxPython so far has been trying

to figure out when and where to use Refresh/ForceRefresh/Update/Repaint etc.

I find I don’t need them often – I think the trick is to be more

event-driven – i.e. don’t put all that in one event handler.

wx.CallAfter is a really handy way to throw something on the event

stack, so it’s easy to keep separate things separate.

-Chris

I totally agree. I almost never need to use any of those. The only related method I use from time to time is Layout() when I add/remove a widget.

  • Mike

The thing to remember is that Refresh causes the window to be "invalidated" which will cause the system to queue an EVT_PAINT event, and Update causes any pending paint event to be processed immediately (while in the Update call).

ForceRefresh is a Grid-only thing that basically side-steps some optimizations that the Grid is taking to avoid repainting too often, but you really shouldn't need it.

···

On 6/5/12 12:08 PM, Nicholas Montpetit wrote:

Chris, thanks so much for your help! Using the Update() method worked.
Now time to bring in multithreading to make the app more responsive.

One of the most challenging aspects of using wxPython so far has been
trying to figure out when and where to use
Refresh/ForceRefresh/Update/Repaint etc.

--
Robin Dunn
Software Craftsman

Thanks again to everyone for your help – wxPython has such a welcoming and helpful community!

Robin, thanks for writing the excellent “wxPython in Action”. It’s probably my most frequently used book!

-Nick