Increasing Num Legend Rows crashes LV if Stacked Chart

[Brinoceros]

Hi Steve,

Your most recent issue in this thread has come to my attention.  I have been playing around with the situation and have come across the same behavior: when built into an exe it seems that the LegNumRows property does not respond when written to using VI server.  I tried a few other properties, but have not had the same issue.  I will go ahead and look into this further to see if I can find a reason for this behavior.

In the mean time, do you require another work-around for this?  It seems there have been a number of suggestions on this thread, so I just want to ask you if you absolutely need to control your chart in exactly this manner, or if any of the other suggestions will suffice.

Again, I will look into this a bit more and let you know what I can come up with!

[SteveP]

Brian,

I do not believe that there have been any other suggestions that allow the number of plots in a stacked chart to be changed (increased or decreased) at run time in an executable.  Please point out any that I may have missed.

Steve

[Brinoceros]

Hi Steve,

Sorry, I probably shouldn't have said pluralized suggestions; I meant the solution posted by Spex.  I also had not noticed that the initial problem was in an executable deployment.  Obviously I see that this is now the situation, so here is what I have for you.

What you have come across building this into an exe (the fact that LegNumRows no longer seems to update) seems to be unexpected behavior.  This was reported to R&D (#118567) for further investigation.  Being able to write to this property is actually a new feature to LabVIEW, and it seems it might still have some small bugs.

Unfortunately it looks like this puts us at a bit of an impasse with what you are trying to do.  Try to see if there may be some other way to architect your program in order to avoid this.  And if there is some way I can help, I will do my best!

[coobery]

I think SteveP is a good LabVIEW's guys,

he can find some very small bugs  that others cannot  take notice.

[SteveP]

Another NI Application Engineer has submitted a Corrective Action Request (CAR) to R&D # 119863.

Steve

[Brinoceros]

FYI, the previous report to R&D (#118567) is already slated to be included in the Labview 8.5.x Known Issues document.  It is not listed there yet, but I thought I would let you know that this number will most likely be the one you would want to reference in the future, if you wanted to check up on the status of the bug.

Thats all.  Cheers!

[CAC10268]

I know this is an old post but I have come across this exact problem using Labview version 8.5.1f4.  It returns error code 1000 when I try setting any value to the LegNumRows property of a Waveform Chart. This issue has been reported to NI as stated in the previous posts, but it seems like it hasn't been fixed. Is anyone else still experiencing this bug...? Thanks in advance.

-CAC

[Ben_S]

CAC,

Hello! I apologize that you are experiencing this issue! However, as this forum indicates, it is a very known issue that has been reported to R&D for multiple scenarios. There are a few workarounds for this issue that have been posted on this thread. Please let me know if you have trouble implimenting the mentioned workarounds.

Thanks!

[Spex]

CAC10268,

In particular, look at this post earlier in this thread for a reason why you are getting error 1000.  It states that prior to LabVIEW 8.5, the property node you are trying to call was not supported during run-time execution of a VI, and therefore returned error 1000.  For some reason, this property stopped returning that error and appeared to work in LabVIEW 8.5.0 somtimes, but would often crash your application.  Therefore, to address the situation in 8.5.1, it looks like the developer decided the best option was to revert to the 8.2.1 behavior, disable the feature and return error 1000 one again.  I have not revisited this feature in 8.6 or 8.6.1 to see if the behavior has changed since then.

For a workaround, in particular, view this post. This demonstrates a hack of changing the number of plots by changing a chart in a sub-panel that is not in "execution state".  Be warned, this is not a perfect workaround because it will not be as high performance as updating a chart in the native window, and there are issues that SteveP found with naming plots in the plot legend, and with deploying this front panel strategy in an executable.  The first issue could probably be worked around with another handful of property nodes, but no one has suggested a workaround for the second issue.  Both have been reported to R&D as shown later in this thread.

Good luck,

[SteveP]

Spex,

The error 1000 still exists in 8.6.1 and if you are a beta tester, you can determine whether it still exists in that version.

Steve