Image Display got rotten (really: the Indicator, not the Image!)

[Enrico_Segre]

I'd like to hear comments on the following VI, containing just a single Image Display Indicator, which, for some reason got corrupted during porting across LV versions and resizing. By divide and conquer I found that it was the origin of pretty odd problems that I was observing in a complex VI: absence of front panel updates, pull down menues not displayed, actions needing a double press of buttons, and so on.

The VI is saved from LV2012 windows, also attached as saved for 8.5. Just opening it, on 2 installation of Labview, I turn labview into something responding oddily. (try to pull down a menu, e.g.). Linux LV seems not to suffer from it, maybe because it places a nonfunctional FP placeholder for this control, without trying to cope with its nonfunctionality.

The question is perhaps, why LV doesn't detect the problem and behaves so weirdly with it -- bug?

Enrico

[Blake-C]

Enrico,

Are you able to replicate this with another VI? If so, how? Can you replicate the issue in multiple versions of LabVIEW?
What more specifically do you mean by “porting across LV versions”?
Does this happen with other VIs or just this specific one? Are you able to run any VIs with image indicators?

[Enrico_Segre]

Would I be able to take a normally behaving Image Display indicator, feed it to an army of students, copy the VI across computers, save it back and forth in different LV versions, and end up again with something that messed up -- surely not.

I speculate, but it is really just a speculation, not knowing the internals, that the Image Display includes some kind of code for callbacks [which would also make sense -- for example hovering the mouse over an image displays the coordinates and the pixel value] -- and that some part of it got so much messed up that it interferes with basic FP actions such as displaying contextual menues and refreshing the screen.

Do you see the same I described if you open what I have attached?

[Blake-C]

Enrico,

I was able to see what you were describing with the VI you posted. I’m not sure why that would occur going between versions but your assumption of something getting corrupted seems correct. As far as why this happened and what (at a low level) happened, I’m not sure and it would be difficult to find out what exactly happened without being able to reproduce the issue and find a pattern.

[Enrico_Segre]

One of the uncommon aspects in this control is that the image tools are displayed in a row rather than in a coulmn (I have the vague remembering of having resized them as an array container at some point -maybe that was possible in LV8 or 8.5, where the VI originally was, before reopening it in 12 and saving it back for 11). But I can't say either that the horizontal resize was the initiator of the malfunctions.

[Andrey_Dmitriev]

Yes, I was able to see this trouble as well. Checked in different versions (2010 and 2012 x86/x64). But was unable to re-create this VI from scratch. It seems to be that Vision Control was broken in customization attempt where cluster with buttons was rearranged from vertical to horizontal position (may be in combination with saving for previous LabVIEW version).

Time to time I do the same (for example save VI with vision controls from v. 8.6 to 7.1) and I've got lot of situations when "downgraded" VI cannot be opened or caused just crash, or broken. Something is wrong.

Quick and dirty analysis of the given "BadImage.vi" shows that the problem with refreshing is present. LabVIEW tries to refresh this control continuously.

In Process Explorer we can see one thread with 100% CPU load (overall 20-25 percent, because I have 4 CPUs):

In Call Stack we may see DrawImageControl function which is called from niviswnd.dll.

Well, load this stuff into debugger, set breakpoint and see - this function called continuously:

called somewhere from SetPIClusterPartSize from LabVIEW.

I don't want to go deeper into call chain analysis (anyway makes no sense without source), but short walking in debugger shows that messages continuously fired:

Check it with Spy:

There are thousands WM_PAINT messages which continuously sent to the Window with this weird control. Looks like attempts for update, but due some internals errors this called again and again.

The messages queue is full with WM_PAINT - therefore LabVIEW is "unresponsive" - context menus cannot be shown, dialogs cannot be closed, slow reaction, etc.

Sorry for slightly off-topic above, but may be this will be helpful for NI's engineers for further investigation.

Andrey.