Nasty bug with tables (LV 8.2)

[BrianInTheForest]

I sure hope it is going to be fixed.  Maybe I should just go back to 8.0 then if it is not going to be fixed.  I have caused my program to crash numerous times by clicking on the table to look at some data.  This is one irritating bug.  I guess I can convert my array to spreadsheet string and output it to a string indicator instead of a table.

Brian

[Ben]

I second Joe's reply.

So what can you do now?

Once a CAR (Corrective Action Report) has been filled, it will be passed to the appropriate group in R&D.

They will address the severity of the bug and it will be scheduled to be correct as indicated.

Once a developer get the reports and fixes the bug, the "fix" will subjected to ALPHA testing and then BETA testing.

If you know the CAR # (in this case "41I6CPA4" ) customers with a valid support contract can contact NI-Support and request a status update on the CAR.

So....

If you really need the fix, and are willing to live with the limitations of working with BETA ( see reply #40 in this thread on LAVA

http://forums.lavag.org/index.php?showtopic=2840&pid=17083&st=30&#entry17083

where Rolf Kalbermatter wrote "There are better ways to commit suicide " )

you may be able to get an early version of the fix.

Ben

[JeffBoettcher]

I will go one better and say that it is likely that an issue of this severity would be fixed by a maintenance release (i.e. something like an 8.2.1) should NI issue one for 8.2.  However, Ben's comments are correct too - such a release needs to go through rigorous testing, and I can't say at this point for sure when or even if such a maintenance release will be issued.

[bww]

I too am experiencing this crashing problem. Just for completeness, I'm using a compiled vi in embedded XP. Not that it's important but it seems to crash immediately in the compiled version where as it takes a couple clicks on my development machine, which is regular XP. Anyway, so I have an idea for a work around, which I've partially tested. If the table is disabled, the program does not crash. So it should be possible to disable the control and then programmatically add/update the table through property nodes and other controls. I am only using the table to display messages and I don't really need the user to interact with the indicator. I imagine that this might be a bit of extra code but sounds possible. Any thoughts on the idea? I'll re-post if it works out. 

[bww]

Just to follow up with my previous post, the work around that I suggested does in fact work, atleast for my application. Please see attached vi. It turns out that the crash only occurs with the table being an indicator and not a control.

Regards,

Bryan

[AdDekkers]

Solution (work around) !

Place an (invisible) decoration on the table and the problem is solved!

[AdDekkers]

You can click in and out the table or copy data from the table without crashing labview now!

I have attached an example.

[Jaegen]

Whoa - that's wierd.  I thought you just meant to cover the whole table with a decoration (i.e. to prevent it from ever being clicked).  But, as your VI shows, all you need is a decoration covering part of the table.  Even with a 5 x 5 pixel decoration (apparently the smallest we can get) right in the bottom corner this works.

Thanks for this - it makes a huge difference for us.

Jaegen

[Roy_F]

---

@Jeff B wrote:

I'm sorry I don't have a fix for you now, but I thought I'd at least let you know that this was reported to R&D (41I6CPA4) for further investigation.

---

For tracking purposes, the above problem report (41I6CPA4) was closed as a duplicate of 40A8TF70.
This was reported to R&D (# 40A8TF70) for further investigation.

Roy

[Kravlor]

Thank you for the workaround, however strange! After arguing for months to upgrade to LV 8.2 in my research group, we finally did so -- and then got bitten by this horrific bug. Is there some sort of mailing list we can be put on to find out when the official fix is released?