8.5 LVOOP Upgrade Problem

[Clicker]

I have taken the plunge to 8.5 and started converting a large project that I am working on. Everything was going sweet, so I figured I would add a new class. (On a side note it's much easier to add methods now with the additional templates.) And then it hit, that blahblahblah.cpp error, line xxx. Ugh! So after restarting LabVIEW and opening my project I found my classes are now broken. Since it's only affecting the ones inheriting from a specific parent class I thought it might be possible to change inheritance just to get a better idea what the damage is like. Well I can't even do that, while attempting to change inheritance LabVIEW will lock up and eat away at CPU cycles.

Here is what I am seeing. Any suggestions or ideas on how to recover from such a mess would be appreciated.

Thanks.

[Tomi Maila]

Have you tried opening all main level VIs and then pressing ctrl+shift+run on one of them. This forces LV to recompile and the bug may disappear... I've had similar situation a few times and recompiling has helped.

[Clicker]

Yes, this was one of the first things I tried. Unfortunately it didn't help. I also tried replacing the broken class control with the one defined in my class, but that didn't have any affect either.

Luckily I did make a backup copy before moving to 8.5.

So LabVIEW 8.5 will use my class in the original 8.2.1 format but after re-saving and then opening it again everything breaks. Perhaps something is wrong in the new file format which I find very discouraging.

[Clicker]

I have identified the problem lies with using a VISA control in the class data definition. After changing it to a string in 8.2 and then saving it again in 8.5 the problem is no longer preset.

I'm in contact with NI and will post more details as I get them.

[Aristos Queue]

QUOTE(Clicker @ Aug 9 2007, 06:51 PM)

Here is what I am seeing. Any suggestions or ideas on how to recover from such a mess would be appreciated.

Your .lvclass file is corrupt; more specifically, the .ctl file inside the .lvclass file is corrupt, but it amounts to the same thing. I don't know how it got to be corrupt (that blahblahblah.cpp message would be useful in ascertaining that).

QUOTE(Clicker @ Aug 10 2007, 12:25 AM)

So LabVIEW 8.5 will use my class in the original 8.2.1 format but after re-saving and then opening it again everything breaks. Perhaps something is wrong in the new file format which I find very discouraging.

Far far more likely is that something is wrong with the original 8.2 file format and the now corrected 8.5 file format is having trouble interpreting it. There is one known issue along those lines (I put in special code to recognize the corrupt 8.2 files and fix them, but you may have found another form of the corruption). Or it could be as you say, a corruption of 8.5 itself.

I'm playing with the files a bit to see if I can get some more info.

[Clicker]

I do thank you for taking a look at this in more detail.

I also thought it could just be a file corruption or something along thoses lines so I did a few 'experiments' to determine it was the VISA control after it was converted and saved in 8.5. One of those was to create a new class from scratch containing the VISA control itself in 8.2 and then update it to 8.5, after resaving it and attempting to close/open it had the same issue. Then I used that same class created in 8.2 and just replaced the VISA control with a string control everything worked nicely. So based on that it leads me to believe something strange happens when converting the VISA control from 8.2 to 8.5.

Its easy enough to just use strings instead of the VISA controls so that is what I did. Perhaps that is the better way of doing things anyhow.

[Aristos Queue]

WORKAROUND FOUND.

Load the 8.2.1 version in 8.5. Open the private data control. Edit it by resizing the VISA resource Name (actually, any edit will do). Then you can save the VI in 8.5 and it will load correctly from then on.

Curiously, you probably (if I'm reading the code correctly) won't be bit by this bug if you load directly from 8.2, only if you load from 8.2.1. *sigh*

This will affect any LV class that has a VISA resource string in its private data control. It is specific to the interaction of those two features.

PS: Do you have a CAR number on this from when you reported it to NI? The bug report hasn't yet percolated to my desk, and I might as well jump ahead of the stream and intercept it at this point.

[Clicker]

Well when I said 8.2 I meant 8.2.1.

But anyhow, yeah thanks for this work around.

So if you don't mind me asking why do you need to edit the control? Does this replace the older control with a newer one?

QUOTE(Aristos Queue @ Aug 10 2007, 02:58 PM)

PS: Do you have a CAR number on this from when you reported it to NI? The bug report hasn't yet percolated to my desk, and I might as well jump ahead of the stream and intercept it at this point.

I don't have a CAR number but I do have a reference number: 7165459. I'm not sure if that is the same or not.

[Aristos Queue]

QUOTE(Clicker @ Aug 10 2007, 05:12 PM)

So if you don't mind me asking why do you need to edit the control? Does this replace the older control with a newer one?

Normally we mark a VI as having a change when a mutation like this is made. That's not happening in this case. But the .lvclass file itself is being marked as needing to be saved. The class saves, but it isn't bothering to update its image of the .ctl because the .ctl isn't marking itself as needing to be saved. When we load the class later, it assumes that the .ctl is the same version as itself, but actually the .ctl hasn't come up-to-date. At least as far as I can tell... Without having actually fixed the bug, there may be further complications that I discover later. But the workaround should be enough for your purposes tonight. ;-)

[Ton Plomp]

QUOTE(Aristos Queue @ Aug 10 2007, 11:58 PM)

This will affect any LV class that has a VISA resource string in its private data control. It is specific to the interaction of those two features.

Is it only VISA resources or also Daqmx resources?

They appear to be the same to me, and I don't want to be bitten by it.

Ton

[Aristos Queue]

QUOTE(tcplomp @ Aug 11 2007, 01:05 AM)

Is it only VISA resources or also Daqmx resources?

They appear to be the same to me, and I don't want to be bitten by it.

One user reports that it also affects DAQmx, but I have no confirmation of that at this time. It is definitely possible.

This issue has been reported to R&D (4CG9B3J1) for further investigation.