Screen redraw error

[Charlie]

I may have missed someone else mentioning this when I searched, but I thought I'd report it. I'm running the latest released version 1.9.1 build 989, on Windows XP with all the latest patches.

Whenever I partially cover the Cumulus window with another window, then drag the other window around, the Cumulus wind rose (only) usually does not redraw properly and retains part of the border of the window being dragged away with multiple copies across the wind rose area, or sometimes even creates multiple copies of the wind rose overlapping each other in the space.

This does not happen every time - maybe 90% of the time, and moving the cumulus window fixes it. Only the wind rose is affected; the rest or the window is fine. I did not see this behavior on previous released versions.

It's just a minor annoyance, with a simple work around, but I thought it should get on the bug list if it's not already there.

[steve]

I can only partially reproduce this. It works fine for me on Windows 7 and XP, but on my WHS server, I do see the redraw problem, but it corrects itself on the next update.

I'm considering reverting to the wind rose that was in 1.9.0 anyway, so this problem will go away, assuming I do that.

[AllyCat]

Hi Steve,

I've seen the wind rose redraw error a few times with XP and personally prefer the appearance of the 1.9.0 version (the nicer character font and maybe the "scale" circles). However, I believe I've found a "bug" in the 1.9.0 software:

The background is that I've been attempting to improve the uniformity of the 16 direction sectors of FO sensors (with some success to be reported soon). There are various ways to measure/demonstrate the results but the simplest and most elegant seemed to be the Cumulus wind rose. For this, I've built a simple test rig to emulate a constant wind speed (it happens to be 10.7 mph) and use a motor to rotate the vane at a very slow constant speed for exactly one revolution.

First I tried one revolution in 12 hours but found that the "history" vanished after 10 hours. From another thread I see that you store 3600 data values which expire after 10 hours, using the 10 second read interval employed with FO devices. In passing, a possible "feature request" could be for an increase to 4320 values which would make the measurement with a 12 hour motor (e.g. a clock mechanism) very easy. Or of course, a user-definable value to allow the "persistence" of the rose to be selected.

So I changed to a motor with 1 rev every 3 hours (it happens to drive anticlockwise). The first 14 sectors are fine but something strange starts to happen in the 15th sector and the rose becomes highly distorted after 3 hours. See the 3 attached screenshots, merged into a single image file - the capture times are shown at the head and foot of each frame. I've repeated this several times with similar results, but the issue does not occur with the Cumulus 1.9.1 rose.

Thanks, Alan.

[steve]

Maybe I won't revert to that gauge after all, in that case. And is it an optical illusion, or is that gauge not actually round?