I'm having some problem with wx.gauge and the Windows 7 theme. My program has 2 computation steps running one after the other. For each of them, I have a gauge. When using the Windows 7 theme (for example 'Windows 7' the Aero theme, or 'Windows 7 Basic', it looks like the gauge is always late. I noticed this also on non-wx applications. In my case, it's so bad that the lower gauge starts growing even though the upper gauge is not all filled up (see the attached picture).
I checked my code carefully and it is clear that the 2 process do not overlap (how would they) and, most important, if I'm using the 'Windows Classic' theme, it works perfectly well, with no weird gauge behavior.
Has anybody encounter this kind of problem ?
Using python 2.7, wxpython 2.8.11.0, Windows 7 Professional.
I assume that you are sure you've set the value to the gauge's max... Is your code blocking the event loop so the widgets are not able to get paint events to update themselves with the new state?
If that doesn't help then please make a small runnable sample that demonstrates the problem. MakingSampleApps - wxPyWiki
···
On 11/2/10 9:18 AM, Raphael Mayoraz wrote:
Hello,
I'm having some problem with wx.gauge and the Windows 7 theme. My
program has 2 computation steps running one after the other. For each of
them, I have a gauge. When using the Windows 7 theme (for example
'Windows 7' the Aero theme, or 'Windows 7 Basic', it looks like the
gauge is always late. I noticed this also on non-wx applications. In my
case, it's so bad that the lower gauge starts growing even though the
upper gauge is not all filled up (see the attached picture).
I checked my code carefully and it is clear that the 2 process do not
overlap (how would they) and, most important, if I'm using the 'Windows
Classic' theme, it works perfectly well, with no weird gauge behavior.
Has anybody encounter this kind of problem ?
Using python 2.7, wxpython 2.8.11.0, Windows 7 Professional.
The gauges increases of 10 % every 0.5 seconds.
Try it using the 'Windows 7 Basic' theme. The second gauge starts growing before the first one is filled up. About 10 % of it is missing until gauge 2 is almost filled up too. This is happening even though I have a 'self.gauge1.SetValue(100)' after the loop that grows the first gauge.
So, something is wrong there. If you follow the printouts, you will see that the gauges are always late (it's even clearer if you increase the time step value). It will printout '10' before the gauge shows any reaction.
Now, most important, try this using the 'Windows Classic' theme: everything works well, as expected, which seems to show that my code should be fine.
I'm having some problem with wx.gauge and the Windows 7 theme. My
program has 2 computation steps running one after the other. For each of
them, I have a gauge. When using the Windows 7 theme (for example
'Windows 7' the Aero theme, or 'Windows 7 Basic', it looks like the
gauge is always late. I noticed this also on non-wx applications. In my
case, it's so bad that the lower gauge starts growing even though the
upper gauge is not all filled up (see the attached picture).
I checked my code carefully and it is clear that the 2 process do not
overlap (how would they) and, most important, if I'm using the 'Windows
Classic' theme, it works perfectly well, with no weird gauge behavior.
Has anybody encounter this kind of problem ?
Using python 2.7, wxpython 2.8.11.0, Windows 7 Professional.
I assume that you are sure you've set the value to the gauge's max... Is your code blocking the event loop so the widgets are not able to get paint events to update themselves with the new state?
If that doesn't help then please make a small runnable sample that demonstrates the problem. MakingSampleApps - wxPyWiki
On a whim, I tried out your sample on linux/gtk. I found that the whole window freezes until the counting is all done. Then the window becomes responsive again, and both gauges are full. This tells me that maybe you should be using threads, I’m going to test it on win7 later, so I tell you what happens!
···
–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!
On a whim, I tried out your sample on linux/gtk. I found that the whole
window freezes until the counting is all done.
same on OS-X. I'm surprised it works on Windows.
Then the window becomes
responsive again, and both gauges are full. This tells me that maybe you
should be using threads,
yup, that or a wxTimer
See the Wiki pages under "long running process"
-Chris
···
On 11/5/10 5:41 AM, Micah Nordland wrote:
--
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
Ok, I tried it on 7, and it does indeed work, but, there is a problem with your code, while the gauge does increase correctly with the classic theme, if you try to move the window, it fades white, says not responding in parenthesis etc. My recommendation is to first make your code non-blocking with either threads, wxTimers, or whatever, and then worry about those gauges. Maybe if you make your app non-blocking, it will clear up the gauge issue.
···
–
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!
No "maybe" about it, it *will* clear up the gauge issue because it is happening due to the event loop being blocked. I imagine that it appears to work in the Classic theme simply because the theme is refreshing the widget more often because of a side-effect of how the theme is implemented. But obviously normal processing of the event loop is blocked, and that is never a good thing to do even when it does appear to work correctly otherwise.
Ok, I tried it on 7, and it does indeed work, but, there is a problem
with your code, while the gauge does increase correctly with the classic
theme, if you try to move the window, it fades white, says not
responding in parenthesis etc. My recommendation is to first make your
code non-blocking with either threads, wxTimers, or whatever, and then
worry about those gauges. Maybe if you make your app non-blocking, it
will clear up the gauge issue.
