Windows occasionally stop redrawing

[Craig_]

Do you have an example of where this affects Windows 8?

From what I can see of our testing it looks like this is exclusively linked to AERO in Windows 7.

[TurboPhil]

Aero still exists in Windows 8. They just removed transparency. It will still be a problem.

[rolfk]

Well the question was if there is any evidence that the original problem may still be present in Windows 8. Just because Microsoft did reuse some of the Aero features such as the compositing window manager with hardware acceleration does not automatically mean that this issue would still be present in Windows 8 as they surely took the compositing window manager under hand when moving to Windows 8 and may have fixed this issue on the way.

So do you have evidence that the stopping of redrawing still happens in Windows 8? Craig claims that their testing only revealed this issue on Windows 7 with the Aero desktop enabled and that disabling Aero is a workaround. Programmatic disabling of the compositing window manager is not an option anymore in Windows 8 but that may not be necessary in this case anyways, since MS might have fixed the issue in the meantime.

[Wolfskill]

"Well the question was if there is any evidence that the original problem may still be present in Windows 8."

That is not the question.  The real question is: is there is any evidence that the original problem doesn't occur in Windows 8?

I don't have Windows 8, so I can't test this on there. Has NI been able to consistently reproduce this issue on Windows 7 and can they run that same code on Windows 8 and show that it is not still a problem? 

[CoffeeBreak]

Hi Wolfskill,

After following the Corrective Action Request (CAR) provided by Travis-E, I have found that this was elevated to another CAR 429724. This CAR lists that this unexpected behavior has been remedied in the LabVIEW 2013 f2 Patch.

[Jeff-P]

Hello all,

To clarify Sam's comment and provide a bit more context - 

CAR 429724 is fixed in the LabVIEW 2013 f2 patch. This was an extremely difficult to reproduce situation where the front panel would stop updating (in an identical way to what is described in this thread). The original CAR discussed is still open (CAR 369142), since it is also a very complex bug that is very difficult to reproduce. As a result, we are still investigating if the fix in the 2013 f2 patch also fixes the issue discussed in this thread. For those of you in this thread who have run into this behavior, can you please send me information about your system (either by post or personal message)? I am specifically interested in hardware specs (processor, number of monitors, video card, etc).

I added CAR 369142 to our Known Issues List . It was actually added a while ago when it was found, but it was not showing up in the list because of a formatting issue. That list is kept up to date and is the best way to track open issues like this. 

Regards,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments 

[Theo_K]

I had this issue consistently. Fortunately I was able to find a workaround, which I want to share with you as this is quite a nasty issue.

ISSUE:

My application’s UI consists of a Main Menu screen, and several “sub-screens”. Each sub-screen and the Main Menu screen open maximised. Sub-screens open in front of the Main Menu screen.

When I was opening and then closing a specific sub-screen, the Main screen which was behind the sub-screen would not re-draw. Most of it had completely disappeared (transparent) and bizarrely only one or two buttons on the main screen were showing, and even more puzzling is that the buttons shown were having their colour refreshed just fine (programmatically depending on a set of hardwired conditions).

SOLUTION:

I tried all sorts of suggested workarounds suggested in the thread above but none worked in Windows 8 (64 bit computer).

Then I decided to try using various VI properties to see if one would succeed in forcing the screen to re-draw.

The “FP.IsFrontmost” property was successful. I called this property each time the offending sub-screen was closed, and thankfully the Main Menu screen was re-drawn just fine every single time.

I have attached a code example image.

Additional info:

This intermittent issue was first seen on a Windows 7 machine and reported by a customer. I was then able to see the issue consistently on a Windows 8 machine (both machines run 64-bit Windows).

The difference between the sub-screen that triggered this bug and all other sub-screens that did not, is that this particular screen contained many more individual UI elements than all other screens, as well as large amounts of data loaded in global variables and in a multi-column list box control. I can’t think of something else.

I hope this helps.

Regards,

Theo

[Intaris]

---

@Jeff-P wrote:

Hello all,

To clarify Sam's comment and provide a bit more context - 

CAR 429724 is fixed in the LabVIEW 2013 f2 patch.

---

If this is really verified to be fixed in LV 2013 f2, can we PLEASE get a fix ported back to LV 2012 SP1?  We have software developed in 2012 which we simply cannot move to 2013 (we would have to update all our customers' RT systems - no thanks).

This problem affects a lot of people and needs to be fixed as broadly as possible.

Shane.

[Theo_K]

I believe I’ve got to the bottom of this. I was able to reproduce the issue and find its cause, as well as a solution. Please read-on for more details.

Firstly let me mention that I am actually using LabVIEW 2013 f2 (32 bit) on a 64 bit machine, 16GB RAM, i7-4770 3.4GHz 8 core CPU, 64-bit Windows 8, and I can confirm that the issue is still present, rather consistently in fact.

Therefore… either the issue has not been fixed completely in LabVIEW 2013 f2, or the issue I am having is similar to CAR 429724 but not exactly the same (note that I have not looked at CAR 429724 but was just mentioned above by other users).

Another thing to notice is that the issue I’ve had was first discovered on a 64bit Windows 7 machine. So it is still present both in Windows 7 and Windows 8 with LabVIEW 2013 f2.

STEPS TO REPRODUCE THE BUG:

Here are the steps that reproduce the issue. The attached image (Window not redrawn.png) captures the issue in the form it materialises in my case.

A “Main Menu” screen which is the top level VI and runs all the time, opens another “sub-screen” (i.e a Vis with its FP open and maximised) by calling that VI in in-line.

Each time the sub-screen VI executes, it sets the Main Menu screen’s panel to “Hidden” (FP.State=Hidden) first, it then makes its own window visible (FP.State= Maximised, FP.IsFrontmost=True)… So far so good.

The problem occurs when closing the sub-screen VI. The sub-screen’s clean up code first opens the previously hidden Main Menu window using (FP.State= Maximised, FP.IsFrontmost=True), and then it closes its own front panel using invoke node (FP.Close). This mechanism is intended to ensure that the Main Menu screen is already visible when the sub-screen is closed. See attached file (Source of issue and solution.png) for actual code that causes the bug to materialise.

The above sequence of steps leads reproduces the issue consistently each and every time. In summary the above sequence makes a hidden panel visible when another panel is already open. The issue occurs at the very moment the hidden panel is made visible and front-most, using (FP.State= Maximised, FP.IsFrontmost=True).

CLUE FOR NI:

I have noticed that the issue occurs with front panels (UI “screens”) containing a Multi-column Listbox control (the MCListbox style is “Modern”) when those front panels contain multiple other control and indicators (references to all those UI elements exist in the block diagram also). The issue did not occur with panels which did contain a MCListbox but had much fewer UI elements. Not sure if this gives away any clues but I thought I should mention it.

WORKAROUND IN MY LAST MESSAGE (non-ideal):

The workaround I described in my previous message above was to open the hidden panel AFTER the panel already open is closed first. Obviously this is not ideal as the transition becomes visible.

NEW PROPER WORKAROUND WHICH ELIMINATES ALL ISSUES:

The lower block diagram shown in the attached image (Source of issue and solution.png) shows the workaround which completely eliminates the issue.

Note that simply setting “Activate = True” causes the issue to re-appear (not sure why, so don’t do that).

Also note that the Main Menu panel takes a few dozens of milliseconds to open after the “FP.Open” invoke node has executed. Therefore I have used a 100ms delay to ensure the Main Menu panel opens before the sub-screen’s panel is closed (which is what actually happens without the 100ms delay in place).

I hope this information will allow people overcome this issue until National Instruments have managed to tackle it at its route, and hopefully it will help NI get to the bottom of this too.

Thanks,

Theo

[Theo_K]

Hi Craig,

I can supply some code that should help NI get to the bottom of this issue.

Thanks,

Theo