Yair

In recent years it was always early-mid February. It's usually also announced in a few places, such as in the NI forums.

I don't remember seeing this at all the last few years, but I don't install the CCT too often. Just now I opened LV 2014 beta 32 bit and VIPM 2014 beta on what is essentially a clean virtual machine and did the following: Searched for "code capture". Chose to install the first option. When asked about contacting the network to get more info said yes. Waited while VIPM downloaded a bunch of spec files which don't actually have anything to do with the package from NI's FTP server. Saw that it says it's "Code Capture Tool v3.2.1-46 by LAVA" and "This Package Conflicts with these other packages: Code_Capture_Tool >= 0.0.1" Clicked the install button and confirmed the license. Didn't see any problems because I don't have the conflicting package installed. I expect that's the same experience most users have and it's the same thing I remember for most of my installs. I don't know what the difference is in your case, since you both say your PCs are also new. Maybe you have some kind of other package which has the old one linked somewhere? Like I said, I didn't deal with the package myself and my knowledge of VIPM package management is basically zero. In any case, you're probably right that having the conflict is not that critical and it could be removed if it's causing problems. I'll let Ton weigh in on that.

Well, I went over the session list very quickly and found more than two or three I would potentially attend, but since you limited us, I'll pick three of those pretty much randomly: TS3281 - Featherweight: Sustainable Application Architectures for LabVIEW TS2879 - A Dataflow Approach to Object-Oriented Programming TS4318 - LabVIEW OOP: Computer Science for the G Programmer Oh, and Nancy's session. And some UI sessions. And more architecture stuff. And the champions' stuff.

It is. Each object is basically a pointer, either to the class default data or to the data of the specific instance (it's actually more than one pointer, but that's not really relevant), so the contiguous space required for the array should be N*pointer size. This information is documented in the LVOOP white paper.

I never looked at the details, but you can examine the VIs LV uses to see the process. Not all of them are unlocked, but some are. Specifically, you'll probably want to start with <LabVIEW>\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\ScriptAccessorVIs.vi

I didn't deal with the VIPM package myself, but if I remember correctly, this was the previous incarnation of the CCT (i.e. the older version was with the underscores and the new one doesn't have them) and there was no way to tell VIPM that this is an upgrade, so it was marked as a conflict to alert the user to uninstall the old version first. I don't know if the only real change was the renaming of the package or if there were other changes which required this. At least I think that's the issue. I didn't check it.

Expanding on Jim's reply, you might wish to just use variant attributes directly for your dictionary. The API isn't exactly the same, but you can use them to do pretty much everything that the library does and they're generally easier and faster to use. The main difference is probably that the container (the variant) is by-val and not by-ref. Regarding your specific question, in the VA case this is done by calling the get primitive without a name. I don't know what the order is (it might be insertion, it might be alphabetical, it might be based on the balancing of the tree). It should be easy enough to check.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Revision-of-many-VIs-written-by-NI-usage-of-the-error-cluster/idi-p/2028642

It is important to define what's meant by "instance" here by the OP. Technically, each split in a wire can (does? depends on how you look at what happens when LV schedules the code to reuse the object in both branches of the wire) also create a copy, which is technically a new instance, but while you can create a constructor VI to init an object, and even create code to make sure the init VI was called, LV does not have the concept of a copy constructor which C++ has (this calls a constructor function whenever you create a copy), so there's nothing to guarantee that a new UID is created at that split. You could call the constructor after each split in the wire, but there's nothing to guarantee it. As you said, by-ref makes this somewhat more controllable in that you define the existence of instances explicitly. But like I said, it should start with properly defining the concept of "instance".

My understanding of express VIs is that they basically run scripting code whenever you make a change in their configuration in order to generate the correct code. It's certainly possible that some circumstance caused the generation to fail in this specific case and to generate broken code. My understanding is that the BDs of express VIs are also saved in some kind of limbo state inside the calling VI, which is why you don't get a better description - the error window does not see the express VI as a separate VI with a diagram in can dig into, so it stops at the caller. It does at least point to the express VI, but I agree that it should be handled better.

I would probably put some focus on the computer science concepts behind LV. Data flow is a different paradigm and understanding that it has an actual CS background can help them appreciate LV more as well as open their minds.

Well, it would work if your code was in an XControl, because they run even when their hoster is in edit mode, but I take it that's not what you want. It might work if you use the VI's Fake Exec State method to tell LV that it's not in edit mode, but I never tried it and it might be unstable. In general, LV still isn't very good at letting you inject behaviors into the IDE itself. I believe that when JKI did their own version with the RCF it was basically code which listened in the background for the hotkey and only when that key was pressed, generated a completely new context menu (which only had the RCF actions, not the standard menu), and I wouldn't be surprised if that menu was actually a separate VI (or at least a context menu on the overlay VI, which was itself a separate VI).

I never tried it myself, but I have heard from people at NI (online, so it should be publicly available if people want to search) that there is an installer you can add when you build an installer which will give the RTE some of the missing functionality. I believe it's called Teststand remote execution support or something similar, so it might not be the exact version that the NIVB uses, but I understand it should work. Like I said, I never tried it, so I don't know any further details and I'm assuming it's not officially supported by NI. Maybe it's not an installer, but a build spec option. Maybe you need to install it separately. Maybe it needs a license. Like I said, search for the details if you want this.

And this -

It seems to work just fine here with a simple example (Win 7, LV 2011). Maybe you should try to find out what the difference is (subpanels?). Regardless, if you have just the single MCLB, you could just appropriate the navigation buttons and use them on it in the panel's Key Down event regardless of whether or not it actually has focus (either by writing the code to control the TopLeft cell or by having them set the focus to the control, which should probably also get it to work). Another alternative might be to make it into an XControl, which might be useful for you if you have this construct in multiple programs (or maybe it's already an XControl and that's the difference?).

I don't know about menu shortcuts, but the QD option should be fairly simple. First, I seem to remember some discussion about this in the QD group a couple of years back, so you can try looking there to see if anyone did anything. Second, if you look at the CCT launcher (in <LV>ProjectLAVA), you'll see that all it really does is get the VI ref and give it to the CCT. Since QD already gives you the VI ref, all your plugin needs to do is call the CCT VI and pass in that ref, and I expect it should work then. Seems easy enough.

Cross post

The other suggestions brought up notwithstanding, you could also simplify the original code by getting rid of the reference check and simply clearing any error at the end. Also, if you do want this, there is already an idea for this, so you could try getting people to vote for it - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Destroy-User-Events-and-Unregister-for-Events-to-Accept/idi-p/1219096 I haven't checked, but I'm assuming that the changes made to events in LV 2013 didn't cover this suggestion. Maybe someone can verify that.

You can see some more details about the change Altenbach referred to here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Change-the-quot-empty-space-quot-cursor-from-the-pointing-hand/idi-p/921548 As is said there, this started with 2012.

Then vote for this, and get others to do so too - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Supercharge-Quick-Drop-Turn-QD-keyboard-shortcuts-into-first/idi-p/2620153 This isn't as convenient as the RCF method, but I expect it should still be usable (and certainly faster, as the RCF has to run the checking VI for each installed plugin every time you right click). Also, you can look into LabVIEW speak and quick edit, which already have a list of options today.

It's not the CCT, but the Get Image method. I reported it to NI a few years ago (gave them the link to this), but I have no idea if they did anything with it. It might be possible to get the background image using some properties and then apply it ourselves, but I doubt it would actually be possible (since you have to somehow draw it BEHIND everything) and I don't think it would be worth the effort even if it was possible.

I also seem to remember people saying that even though the lvproj file is ostensibly XML, merging it sometimes causes later loads to fail (maybe because of non-standard XML or binary elements in it), but I don't remember having practical experience with merging project files. In any case, if you have conflicts, they will have to be resolved (which in LV, probably means using the LVmerge EXE). Additional relevant points: Viewpoint recently released a TSVN toolkit which integrates straight into the project tree and is supposed to be very good and free. I haven't tested it myself because my TSVN version is too old and can't support it. There's a long series of detailed posts about working with SCC in LV, including SVN. It's probably worth reading at least the relevant parts. You can see the list here - https://decibel.ni.com/content/groups/atlanta/blog/2013/11/04/some-basic-git-info

Well, Felicia Day was in both (Penny in *most of* Dr. Horrible, Codex and writer/producer/everything in The Guild), but I liked it not just because it was funny, but also because it presented an alternative model for making quality video content (and Dr. Horrible and Sanctuary also fall into that category, although I didn't really like Sanctuary). I watched most of the first episode of Arby 'n' the Chief and didn't really find it funny (with the notable exception of the million dollars and infinity girlfriends joke), either because I haven't played a single second of Halo in my life or because I've never really been into multiplayer games (the only period in which I did play multiplayer Counter Strike was when I had access to a few networked computers all in the same room and some relevant friends) or because I tend to write more like Arby than the Chief. Incidentally, if there is any one show that I would recommend that every engineer should watch, it would be Mr. Bean, not because it's ridiculously funny (it is), nor because it's one of the very rare cases where I find physical and slapstick humor to be funny (it works because of its suitability to the character and the talent of Rowan Atkinson), but because it's an excellent lesson in problem solving. Mr. Bean is an absolute buffoon, but he's also a genius in finding original and clever ways to solve problems (which admittedly shouldn't have been there in the first place).

Jack, the problem is that you're building a structure on assumptions. AQ asked if people do this (yes) and if it would hurt if it was gone (yes, if only because of backward compatibility). Unless AQ tells us what these wonderful new features are, we have no way of weighing the pain/gain ratio ourselves and I have no intention of playing a guessing game. As far as I'm concerned, if NI wants to have an implicit VI-event structure connection as you suggested, it can implement this by having a right click option on the event structure to say "this is the one event structure, forged by Craig in the fires of the R&D department" and only allowing one event structure in a VI to have this option. I have no idea if this is a reasonable solution, but that's up to NI to say.

The orphans thread was in the BreakPoint. On LAVA you have this thread - http://lavag.org/topic/10729-labview-idea-exchange/