X___

Actually, today I have no such folder issues... 😞 Not sure what's different (beside my MacOS 10.14.4 update). The lag is consistent and persistent. Also, when the path selection dialog pops up, it is hidden by the Wizard's window. Again, no biggie but not usual (actually I have seen such a behavior in Matlab executable - it might be a Windows thing...).

Thanks. I first tried on a network drive (that's how my MBP folders appear on the Windows VM) and it failed the same way I described, so I tried to simplify the path using the Desktop. I just tried a different path (C:\Users\X\Downloads\) and of course that worked... Duh. Another note: the inheritance dialog has a large latency (several seconds) as far as response to user clicks in the tree is concerned. No biggy but not usual...

Old thread, but since interest in the toolkit was rekindled in another thread, I decided to give it a try. I am facing some trivial issues. When I try to create a new control, saving fails in several steps: 1) in the folder selection page, I am first told that a Qcontrol already exists where I know there is none: 2) When I try to circumvent this problem by creating an additional folder and select that folder, the wizard is obviously confused as to which folder I am choosing, as illustrated below: Above, I have created a Q Control folder and selected it, but the final path is bogus... 3) While the above isn't flagged as an issue (yet), creating the class fails (as it should): As a side note, the scrollbar is frozen, so I can't read the full error message... Thanks for checking. Tested on a MBP running LV 2018 SP1f2 64 bit in a Windows 7 SP1 VM (Parallels Desktop).

...

A more granular option than a 3 parts 21+GB download can be found here: http://www.ni.com/gate/gb/GB_EVALTLKTSIGPROC/US The full list of components in the previous suite (2017) is here: http://www.ni.com/white-paper/54231/en/ Having been updated a couple of weeks ago, I am not sure when the equivalent for the 2018 edition will be uploaded, but it provides a good starting point for a systematic search.

Other versions: http://search.ni.com/nisearch/app/main/p/ap/tech/lang/en/pg/1/sn/n8:28,ssnav:pdl/ For more info: http://zone.ni.com/reference/en-XX/help/371361R-01/lvupgrade/labview_features/

For the record, text wrapping in the context Help window has been confirmed by NI support to work as "expected" which means in the following way: 1) if you have a single paragraph with NO carriage return, the text will wrap: 2) If you have a single (isolated) carriage return ANYWHERE in the text (as after the first sentence in the original post), wrapping is suppressed (that's the "expected" behavior according to NI R&D). For instance, if I press return after the first sentence in the Description above, wrapping is suppressed: 3) You have to introduce carriage returns IN PAIRS, in order to get a new line AND preserve wrapping: Of course then you get an empty line that you may not necessarily wanted...

I need some help recovering the trick to use so that a long control description is wrapped properly when resizing the Context Help window (which is not the case in the attached example). I couldn't find anything about this in the Help or in the intertubes, although I can see that I have used some kind of trick in the past to get it to work in some controls. Thanks.

This is the closest thread I could find to bring up the fact that there is no LabVIEW 2017 version available in the profile drop down menu.

Attached are two VIs containing the two objects discussed above. Place them in your "Favorites" palette, choosing to "Place VI Content" for easy access. Types Must Match.vi Type Specialization Structure.vi

For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool. The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried. This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type? Enters the Types Must Match function: I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored. Of course, as the comment on the diagram says: "This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details." Here is the context help for Types Must Match: My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...

Including comments such as "/* Oh well this can get messy."? You've probably graduated from the Concise-Better-Yet-No-Comments School, like I did... I'll leave it to the experts as I haven't the slightest clue which API you are talking about.

I'll take that as a no...

That might qualify as thread-resurrection-and-hijack, but is there any chance to get a 64-bit compatible version of labpython? Currently, after correcting the erroneous path of lvpython.dll in the "PYTHON New Session" VI, loading fails with this pretty explicit message:

Somebody ought to fix that OpenG front page... Graphical!

It does indeed work. Nice workaround. Well that would require me to get into scripting first! But if I ever did and worked on it, I think there is one thing I'd tried to improve on this otherwise amazing toolbox: I'd make sure that wires don't originate necessarily from the "center" of the object, but rather from a natural starting point, such as one of the object's borders, for instance. Kudos anyway! PS: actually there is one more thing, which I think would be a nice addition: when modifying a "weirded" wire, it would be nice to reset the former "weirding" in order to avoid having crooked connections. "Cleaning up" the wire is not a very reliable solution, as NI's "cleaning" algorithm has some uncontrollable tendencies to whip wires around. PPS: and this: allow selecting multiple wires and apply the "weirdiness" to all selected branches.

I have installed the RCF plugin and it is quite amazing. However, I have discovered this little bug. In this situation: Choosing "Round Corners" will result in this: No other "Weird Wire" choice results in an error, so I suppose that there is some weird calculation somewhere, although I could not spot one after a cursory glance at the code.