flarn2006

3 votes for XControls; seems legit EDIT: Oh wow, 7 years since a reply to this thread? I guess that doesn't matter since it's a sticky post though.

VISA is ok but not everyone uses it so...

Oh, no I didn't. I actually forgot that the fixed-length string UI was used for FPGA's.

Oh, forgot I posted that thread. Thanks

If you use Ctrl+Shift+D,|, it will enable logging DPrintf messages. Then you can do Ctrl+Shift+D,P to display a list with most of them: LabVIEW internal debug keys - Ctrl + Shift + D + one of the following | toggle DPrintfs. Currently on. : print global font table A check app heap B print TD dictionary stats D PrintDSStats E toggle QElement checking G toggle StripChart scroll/copybits H show/hide heap peek. I print heap text info J rebuild all malleable instance VIs in current VI's context L prints linker graph viz info M toggle memory checking. N show Ned, the friendly debug options dialog O toggle drawing on/offscreen P prints out this list Q toggle show nonIP terms. currently off R print VI Server info S print net connection table T toggle print compile stats. currently off U toggle sanity checking. currently on for compile/save V print all OLE Variants W show window monitor X toggle new Preferences dialog Z print execution and eventQ status { compact DS now. } toggle gUseNativeFontSizing currently %s " print HeapTextRec line table. ~ toggle unattended mode < toggle clump display (use ctrl-shift arrow keys to cycle thru clumps) & print heap text font runs _ wireframe 3D controls > ActiveX Control Property Browser **** NOTE **** Debug keys are preceded by Ctrl+Shift+D !!!!! **** e.g. Ctrl+Shift+D+N shows the debug options dialog. **** You have 3/4 of a second after hitting the D to hit the N There's a few missing, however. Pressing Ctrl+Shift+D,C makes LabVIEW check the "HedgesSpecialCrash" INI key, and presumably if it's set to some specific value (not True) it'll crash. (Edit: the value is 1, and yes, it crashes with "Hedges Special gDAbort".) Ctrl+Shift+D,+ checks the "FakeInsanity" key; I tried setting that to True but there wasn't any visible effect there either. (Edit: I set it to 1, and Ctrl+Shift+D,+ made it crash when I right click a terminal.) For me, Ctrl+Shift+D,: didn't display the font table, but it checked "HedgesSpecialDWarn". I think the options for this key are "single", "singleLots", "multiLots", and "multi100", though I only tried the first. As expected, it triggered an internal warning. There's also Ctrl+Shift+D,!, which DPrintf's output like this: DPrintfVIObjRefList: [VI "GSW.lvlibp:GettingStartedWindow.vi" (0x0000000006d107d0)] objRefList has 7 obj refs ....[00] (787480577) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006ce0318}, subKind=0, subIdx=-1 ....[01] (882901084) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006ce0408}, subKind=0, subIdx=-1 ....[02] (881852507) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006c89dc8}, subKind=0, subIdx=-1 ....[03] (880803930) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006c7c598}, subKind=0, subIdx=-1 ....[04] (883949661) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cdfaf8}, subKind=0, subIdx=-1 ....[05] (879755353) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cde5e8}, subKind=0, subIdx=-1 ....[06] (884998238) obroFlags=0x200c0000, viRefFlags=0x00000000, h/objID={h=0x0000000006996480,o=0x0000000006cde008}, subKind=0, subIdx=-1

Hedge, is that you? 😉 EDIT: If you don't get it, just pretend I'm insane. Have you tried passing it a preallocated string? preAllocateStringsUIEnabled=True preAllocateUIEnabled=True preAllocateEnabled=True Right-click string control/constant, Set String Size

It would be nice to have it cross-platform, but it's hard to bring myself to ask when you've done so much already! Don't feel like you have to worry about it.

Wow, awesome—I would never have thought anyone would go to so much effort for this! Thank you! I do have one question: what is it that's stopping it from working on Linux/Mac?

Awesome that it works! I'll add it to the LabVIEW wiki. I'm already aware of how to do it on Windows; at first I thought you were saying it works on there too (which I haven't tried in the latest version, but have no reason to think it would work there.)

Has anyone else wanted to be able to simplify their block diagrams without saving lots of subVI's that will only be used once? Like an embedded subVI? I feel like I must be missing something because as far as I can tell, this functionality is already 99% of the way done, and not even hidden. LabVIEW just doesn't ship with one that you can actually put whatever you want inside. And yet, this feature can be trivially created using what I'm pretty sure are all officially-supported LabVIEW features: This is nothing specific to VI scripting; that's just what I decided to use for the example as scripting diagrams tend to become unwieldy pretty quickly. Yes, that's an Express VI. Except instead of a configuration dialog, it opens a blank VI to edit. You can double-click on it to open the VI for further editing. It all saves inside the main VI. And it doesn't even add any dependencies to the VI—dependency-free—the only thing you need the express VI files for is if you want to conveniently edit the contents without converting it to a regular subVI; it'll load and run perfectly fine. Here are the files just in case, but it's not quite refined yet. And again, there might even be something I'm unaware of that makes this unstable or poorly compatible or something, as I don't recall ever seeing this technique used before, and it seems like something that would ship standard with LabVIEW. _SubdiagramConfig.llb SubdiagramSource.llb This is probably better for Code In-Development, but I already typed it all out and uploaded/placed attachments here before realizing, so hopefully a moderator won't mind moving it there for me if I can't do it myself.

LabVIEW's built-in XNode editing tools are enabled using a license file, rather than a simple INI toggle. Presumably they do this for stronger discouragement from unofficial use, as hacking one's way past that feels a lot more "shady" than just adding a line to a config file. But what about the Linux and Mac versions? They don't have a license manager, so how is XNode development enabled there? One might guess that those features simply aren't compiled into the released builds of those versions, but there is actually precedent to suggest otherwise. VI Scripting used to be similarly restricted using a license, but then they made it public. At the time, LabVIEW didn't have a toggle in the Options for it. But they didn't need to release a patch to add one. Instead, they simply published their formerly-internal license file, and set their activation server to accept requests to activate it. And yet, Linux/Mac users weren't out of luck: it turned out that for them, it actually was just a configuration key. The VI Scripting license had the internal name "LabVIEW_Scripting(_PKG)". The Linux/Mac configuration key was "Scripting_LabVIEWInternalTag". At 17:48 in this video, several XNode-related configuration keys are shown, likely found in strings in the EXE or resource files. One of them is called "XNodeDevelopment_LabVIEWInternalTag". Guess what the internal name of the XNode Development license is. I don't have the Linux/Mac version to test with, but I know a pattern when I see one. The following command was given in the readme for the VI Scripting package for Linux: echo -e "labview.Scripting_LabVIEWInternalTag:\tTrue" >> ~/.labviewrc Here are the Mac instructions: If you have either of those versions, it's probably worth a try: follow those instructions, but replace "Scripting" with "XNodeDevelopment", and see if you can open an XNode in the IDE, or create one from File->New. (Also, in the case of Mac, replace 8.6 with your actual LabVIEW version if necessary.) (Here's where I got my information about enabling scripting: https://forums.ni.com/t5/LabVIEW-APIs-Documents/LabVIEW-Scripting/ta-p/3535340?profile.language=en)

Buried inside LabVIEW's resource files are several resources with the type "TMPL". They contain information that looks like it could be incredibly helpful in figuring out the structure of many of LabVIEW's internal resources. They're in a binary format, but it's quite trivial to parse, so I quickly put together a tool for loading and viewing them. Template Viewer.zip For more information, see this page, which appears to describe the same format: https://www.mathemaesthetics.com/ResTemplates.html (Change the URL from https to http; the forum won't let me add http links for some reason.)