Yair

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:

1. Searched for "code capture".
2. Chose to install the first option.
3. When asked about contacting the network to get more info said yes.
4. 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.
5. 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"
6. 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:

1. TS3281 - Featherweight: Sustainable Application Architectures for LabVIEW
2. TS2879 - A Dataflow Approach to Object-Oriented Programming
3. 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.

 

I expect arrays of objects have a level of indirection.... I don't know for certain if this is how LabVIEW operates...

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.

Just be careful with this vi, because it doesn't have an error out.

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

Followup food for thought: if you use unique ID's you probably need to use a constructor type VI. There's no way to enforce this in LabVIEW, but it's something that you can document and check for at runtime. If you do things By reference you can enforce the constructor a little better, you get a built in Unique ID (the reference value), but now you have all the additional concerns of a by-ref architecture. Unique IDs are not enough of a reason for me to switch to By-ref, but they could be one check in the "pro" column that I would consider when designing the entire system.

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".

Where did that come from? Is this just a bug in the expressVI code? Is there a way I can get rid of it without irreversibly converting the expressVI to a normal VI?

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).

No you haven't dreamed but the Vision Builder makes use of a NI special runtime engine that is located in lvfrt.dll. This is a private build that supposedly works as a runtime engine but with most of the compiling and other full development system still in place. However I have no idea how one would create an installer that deploys this runtime version rather than the standard version.

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.

I've tried setting the focus back to the MCLB from the value change event of the SB, but that doesn't seem to work either.

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.

Thanks for the info.  I like the quick drop functionality as well, especially since it works every time.  But I think the way the right click framework worked was so much better IMHO.  I like being able to right-click on something and a list pops up of the functions that can work on what I've selected.  Much better than having to memroize a bunch of shortcut keys or having to do more mouse clicks.

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.

Cross-post from NI Forums http://forums.ni.com/t5/LabVIEW/How-can-i-change-the-background-of-labview-front-panel/m-p/2696525#M801184

 

Code Capture tool ignores Pane Background for Front Panel.  (Minor, but notable)

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

I mostly enjoyed The Guild, probably because I was way into World of Warcraft for a while and could relate to the situations.  But it pales in comparison to the best web show I've seen:  Dr. Horrible's Sing Along Blog.

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/

AQ: do you recall any early caveats from NI (either in release notes, or help, tutorials, online discussion, etc.) that warned against the practice?  I'm vaguely recalling there was an issue with the way ESes invoked some behind-the-scenes setup as soon as the VI was loaded into memory, well before user code started executing.

I don't know about NI specifically (although the caveats section in the LV help might refer to it), but I do remember people being quite forceful about it, probably due to lack of knowledge.

What is true (and I'm guessing those were the problems LogMAN had) is that if you use the same registration refnum for more than one structure you will get undefined and extremely annoying behavior. That's a big no-no and it's a very easy mistake to make if you're not aware of the issue. The caveats section should have some text about this.

In general, if you know what you're doing, you can do quite a lot. I would highly recommend watching Jack Dunaway's presentation from NIWeek 2013, as it's the most concise and understandable coverage of the various points that I've seen. You can find it here - http://lavag.org/topic/17040-niweek-2013-videos/