Darren

I'm not sure how you got into this state, I don't see the hidden terminals in scripting. And if you delete those wires, there's no way to get back to the hidden terminals. Also, I got a DWarn when I copied your snippet into my diagram. So I'd chalk this up to some weird corner case/corruption and move on.

There's a private 'Operate Menu Dismissed' event that may help in this situation.

Can you attach a simple write VI and read VI that demonstrate the issue?

51 minutes ago, the_mitten said:

Huh. Yeah, I didn't expect this. Doesn't this suppose that the user hasn't changed the displayed label text for the subVI?

It's impossible to change the label text of a subVI. That's why this works.

19 minutes ago, ShaunR said:

It does surprise me. I would have thought an entry for VI Type would have been added to the enum.

Yeah, I think the explanation given to me was that the contents of the .vim file on disk are no different than the contents of a .vi file on disk. So since it's technically not a different file type, they thought it didn't warrant a new enum entry. Kinda like how there's not a "Template VI" entry in the list since .vi and .vit are the same type on disk. I may be misremembering though so don't take this as the official answer.

2 hours ago, jacobson said:

I'm not sure what the best way would be to figure out whether the subVI is a VIM.

It may surprise you that this is the best way:

You can also press Ctrl-Shift-E from an open VI to select that VI in the project explorer.

All of the functionality provided by the Icon Editor UI is also available programmatically with the LabVIEW Icon API, available here:

[LabVIEW 20xx]vi.lib/LabVIEW Icon API

This API, along with many others, is described in my Hidden Gems in vi.lib presentation.

There's more where that came from.

It's not a G-based dialog, so to my knowledge, there's no way to launch it programmatically.

I wrote this nugget a long time ago, but the tips are still applicable:

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-30-2006/m-p/434181

rolf's explanation is the best discussion of the string range rationale I've seen:

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-03-09-2009/m-p/867644#M392955

Yes, that's right.

Another option is creating a lv_new_vi.vi in that same folder. This VI will override the behavior of pressing Ctrl-N. You can find the required conpane for the VI on labview wiki somewhere, but I think it's just 4x2x2x4 with an I32 in the upper right. Unfortunately (due to its age as a feature) it has no knowledge of application instances, and thus doesn't work properly when pressing Ctrl-N under different containers in the project window.

This is a C-based dialog, it does not have a G implementation that you can modify.

1 minute ago, Jim Kring said:

I'm looking for a way to change a visible state of a Case Structure, and (A) not have this show up in the Undo Transaction history and (B) not wipe out the undo history. Right now, if I don't create an undo transaction for the visible frame change, it wipes out the undo history :-(

I don't know of a way to accomplish this. As discussed above, changing a VI with scripting requires the Transaction methods to preserve Undo history. To my knowledge you can't modify a VI with scripting, have that modification not show up in the Undo history, but preserve the previous Undo history.

I recently dealt with this issue when designing the LabVIEW Cloud Toolkit for AWS. I had to create a lot of new error codes, that mostly correspond 1-to-1 with the errors that AWS can return. My ultimate solution was that I had an Excel spreadsheet per class (Core, S3, SNS, SQS, IoT), and a build tool that parsed these Excel files and created a separate error text file for each class.

Assuming you're talking about the Data Type Parsing VIs in LabVIEW 2015 and later, you can read the documentation on them. Or you can watch my Hidden Gems presentation in which I describe some use cases for their predecessors, the VariantDataType VIs.

I'm not aware of any intentional changes in LabVIEW 2016 that would cause this. Please post the question to the LabVIEW forum on ni.com so an AE can investigate the issue and file a CAR if necessary.

6 minutes ago, hooovahh said:

So on the topic of weird LabVIEW stuff I had a few today.  I noticed a couple my quick drop functions not dropping what they should be.  Now this might just be a result of my custom quick drop shortcuts, but I don't have any shortcuts for the Copy or Delete functions.  I recorded my oddness here.  Anyone seen anything like this?

Nope, I've never seen that before. You specify the name of a primitive, the thing that gets put on your cursor looks like a Place VI Contents VI of some kind, but then it drops a constant? Go home LabVIEW, you're drunk.

Just now, smithd said:

My problem is that it regularly fails to send the logs up, even when I'd like it to.

Maybe zip up all the logs every once in a while and send them to an AE? They're located here:[LabVIEW Data]\LVInternalReports\LabVIEW

4 hours ago, shoneill said:

How does NI propose we document these problems without sending a complete VM with LabVIEW installed AND complete source code for our project?  Sometimes these problems just get swallowed whole by the inconveneice of trying to demostrate their existence.

I don't have a good answer for this. I run into the exact same issues, and I work at NI! For a while I would file CARs with a [hard to reproduce] tag on them, but I don't think anything ever came of those. I've heard of customers actually visiting NI and bringing their entire setup to get an AE to spend days troubleshooting issues like this, but I think that's overkill in almost all cases.

One thing I can say...I've heard customer sentiment that it's not worth the time to submit NIER crash reports, but that's absolutely *not* true. With each LabVIEW release since NIER's debut, we've fixed *several* crashes as a direct result of the crash reports that were sent in. So continue submitting crash reports (and attaching code where possible and appropriate), because improving stability by solving NIER-reported crashes is something we're committed to with each release.

On 7/19/2016 at 7:08 PM, John Lokanis said:

Why does LabVIEW (almost always) crash when trying to undo the Remove and Rewire and the Insert Multiple Wires QD shortcuts?

On 7/21/2016 at 3:25 AM, shoneill said:

Crash when undoing QD. QD is buggy or is using unstable methods.  We've had several cases of QD shortcuts creating corrupt control references which ended up costing us days of debugging to find.  Random crashes and general instability ensued.

I feel confident in claiming that I use Quick Drop more than anyone on this planet. I use these shortcuts (Remove and Rewire, Insert) dozens of times a day. I've never seen the instability y'all are talking about. No crashes, no "corrupt control references". I've also never seen a CAR reported on these issues either.

I'm not discounting the fact that y'all are experiencing these issues. Believe me, I hate it as much as anyone when the car repair guy tells you that there's no way your automobile can be malfunctioning in the way you describe. But if y'all are seeing these issues as frequently as you claim, why have I not received a bug report that I can investigate? I realize that it's sometimes hard to get things into a reproducible state that can be reported. But hopefully y'all also realize there's not much I can do when the first I hear of these issues in 8 years of the feature's existence is on this LAVA thread.