dadreamer

Okay then. Your software - your rules. 🙂 I'm just worried about some cases with it, so I'm going to ask. As I'm mostly work on modern LabVIEWs (2018, 2019, 2020) and your tools weren't tested on anything higher than LV 2014... What is the worst thing that can happen, when I try to unpack/pack such VIs? Could those be not fully unpacked or packed? Or something got corrupted? Is it safe to ignore the frequent warnings on VI (un)packing? There are always few of them, e.g. Block b'VICD' section 0 XML export exception: The block is only partially exported as XML. , Block b'VICD' section 0 binary prepare exception: Re-creating binary is not implemented. , Block b'VICD' section 0 left in original raw form, without re-building. Sometimes I saw the message "No matching salt found by Interface scan; doing brute-force scan", when packing back VI w/ some sections slightly modified. It then leaves me waiting to get the process finished (honestly, my biggest record is 10 minutes 😄, I always interrupted it). How/what could I do to escape that? Is there some option to force the recalculation, like in flarn's utility (fixing checksums)? It works fine even on the recent LabVIEW 2020. Do you mean rewriting pylabview for my needs? Even if I, say, want to rename some section? I imagined that as few additional parameters, e.g. "section" and "new section", and that's all to do the job. And no need to repack everything. Ok, how could I easily rename some section, having all the VI's files already extracted? I don't worry about the times at all now, as it's not for my work tasks. I experiment with that mostly for my own purposes. I'm aware of tools like that and use some. Thx for the advice anyway. This is not a question of finding some proper addresses in memory for me, it's all about universality. 😉 In the past I already made some plug-in, that was relying on the internal memory offsets. It was a total pain in the ass to find and code correct offsets for each and every LV version. And that was even much more pain with each new LV version, because there were absolutely new offsets. So it was requiring a large amount of time to provide versatility. Finally I gave that up years ago. Since then I hate hard-coding variables based on unreliable internal knowledge, such as memory locations etc. That may change and changes rapidly and all the code goes to trash. I prefer not to write such programs at all.

Thanks, I will take a look, when will have fun studying any VI internals again. Could I request one more feature, if possible? It would be very nice to have a support for in-place sections modification (e.g., type, id or binary contents), without unpacking into .xml and packing back (like in flarn's utility). I assume, the checksums should be recalculated, if dependent sections are altered, as it's already done for the password option. That would save time on simple binary operations. Meanwhile I was going to make a VI to show/hide those toolbar buttons, just for fun. Reality shows that the offsets in VI's memory are varying vastly between different LV versions, bitness and IDE/RTE mode. So likely I won't be posting that. I just put this little picture, so you could name ViBhBit3 and ViBhBit4 bits in ButtonsHidden field. I suppose the rest of the bits is for reserved purpose and does nothing, but I'll recheck on older LV versions and update this posting. Now closer to your code: class VI_BTN_HIDE_FLAGS(enum.Enum): """ VI Tool Bar Buttons Hidding flags """ RunButton = 1 << 0 # Indicates whether to display the Run button on the toolbar while the VI runs and when it's in edit mode as well. In LV14: Customize Window Apearence -> Show Run button. When off also hides Run Continuously button. SetBPButton = 1 << 1 # Set Breakpoint button (LV 3.x and earlier). StepIOButton = 1 << 2 # Step Into/Over button (LV 3.x and earlier). When on the button is shown, but disabled (inactive). PauseButton = 1 << 3 # Indicates whether to display the Pause button on the toolbar while the VI runs and when it's in edit mode as well. Not implemented in LV as a separate GUI setting. DebuggingButton = 1 << 4 # Indicates whether to display the Highlight Execution, Start Single Stepping (Step Into, Step Over) and Step Out buttons on the toolbar while the VI runs and when it's in edit mode as well. Not implemented in LV as a separate GUI setting. FreeRunButton = 1 << 5 # Indicates whether to display the Run Continuously button on the toolbar while the VI runs and when it's in edit mode as well. In LV14: Customize Window Apearence -> Show Run Continuously button. The button isn't shown, if Run button is hidden. LogAtCompButton = 1 << 6 # Log at Completion button (LV 3.x and earlier). AbortButton = 1 << 7 # Indicates whether to display the Abort Execution button on the toolbar while the VI runs and when it's in edit mode as well. In LV14: Customize Window Apearence -> Show Abort button. ViBhBit8 = 1 << 8 # unknown PrintAtCompButton = 1 << 9 # Print at Completion button (LV 3.x and earlier). EditRunModeButton = 1 << 10 # Change to Edit/Run Mode button (LV 3.x and earlier). ViBhBit11 = 1 << 11 # unknown ViBhBit12 = 1 << 12 # unknown ViBhBit13 = 1 << 13 # unknown ViBhBit14 = 1 << 14 # unknown ViBhBit15 = 1 << 15 # unknown --- Here's my "dirty"/hacky tool to show and hide all the toolbar buttons: But_Show_Hide.vi Tested that on LV 2009 to 2020 (both 32- and 64-bits). Maybe it will work on anything newer than LV 2020 in the future, nobody knows yet. It won't work on versions older than LV 2009, because the difference between LV 2009 and LV 8.x is way too large. And I will not be maintaining this tool at all, as it's (almost) useless for anyone including me. Use it as is or forget it. Small update: In LV 3.1.1 and earlier ones there was no separate Tools palette, all the tool buttons were on the toolbar. Here's how it looked for stopped VIs: This was for running VIs: Button 2 ("Pencil with Run arrow") was for switching between Edit and Run modes, button 5 ("...") was to set a breakpoint on the VI, button 6 ("___") was to pause the running VI, buttons 8 and 9 ("Run arrow with file/floppy") were to enable logging or printing respectively at the VI completion. Sure you know the rest. When pressed button 5 was turning into "!" button (breakpoint was set). When pressed button 6 was turning into "Square wave" button (to unpause the VI) and was showing "Single square step" button (to step into/over the VI nodes). Here's how those buttons looked pressed: I've updated the corresponding bits in my tool to reflect those early buttons too, even though the tool won't work on anything lower than LV 2009. The source of pylabview might be updated accordingly.

I'm unable to invoke Heap Peek with the keys combination on VM with Ubuntu. I would check on a common installation, but don't have one ATM. But adding various tokens to the config file (/home/<username>/natinst/.config/LabVIEW-x/labview.conf) works fine for me.

Here's the version back-saved for LV 2011: HeapPeek_WinMonitor.vi Heap Peek and Window Monitor are both available on Linux and macOS. And if one wishes to recreate these brown nodes manually, then (s)he should put SuperSecretPrivateSpecialStuff=True into LabVIEW.ini and restart LabVIEW; when done, a number of hidden private nodes appears.

Okay, now that is simplified. To extract VIs out of .lvlibp (no matter, if FFF-enabled or not): Open extract_lvlibp_vis.vi (attached -> extract_lvlibp_vis.vi ), set path to your PPL (.lvlibp) and the destination folder and run the VI. The files should be extracted and placed to the chosen folder. Extract the inner resource blocks from a single VI with readRSRC.py -x -i "YourVI.vi" command. YourVI.xml and a bunch of various resource sections should appear. Open YourVI.xml and change the library name extension from .lvlibp to .lvlib (between <LIBN></LIBN> tags). Remember the .lvlib name. Save and close the .xml. Pack the .xml and all the resources into a single VI with readRSRC.py -c -m "YourVI.xml" command. You should get YourVI.vi recreated. Do not open it yet. In LabVIEW create new empty library and save it into the same folder, where YourVI.vi resides. Use that name, you obtained on the step 3. Now drag YourVI.vi from the folder into the library's root. LabVIEW should reload the VI from the new path and report. * Untie YourVI.vi from the library w/ RMB -> Remove from Library menu option, save both files w/ File -> Save option. Now you may close YourVI.vi and open again to make sure, it's not broken. Optionally repeat the steps 2-7 for any other VIs from that .lvlib. To extract VIs out of .exe (for non-FFF EXE's you finish on the 4th step): Open YourApp.ini and add two lines to its end according to this article. Launch YourApp.exe and leave it in this state. Open extract_exe_vis.vi (attached -> extract_exe_vis.vi ), set path to the destination folder and run the VI. The files should be extracted and placed to the chosen folder. Make sure, you're using the same port number, that you've set on the step 1. If 3364 doesn't work for some reason, try another number (3363 etc.). For EXE's without FFF option: Now you may open your VIs and make sure, they are fine. For EXE's with FFF: go to step 5. Load a single VI into flarn's Resource Editor. ("Load" button). Find CLIv resource section and change its Type to LIvi. Find CLId resource section and change its Type to LIds. Save the VI with "Save" button. Don't do any other actions here like fixing checksums or whatever. Now you may open YourVI.vi to make sure, it's not broken. Optionally repeat the steps 5-8 for any other VIs from that .exe. * N.B.: In projects with more or less complex hierarchies it might be a good idea not to untie your VIs from the library, because it's very easy to mess with the correct order of such an unlinking. When done incorrectly, your VIs could become broken and to fix them you have to recreate the original VI(s) from the .lvlibp. Also to note, such an untying doesn't work neatly for VIs of different levels of dependence, i.e., a VI has some SubVI(s) and they all are contained into that .lvlibp; on unlinking them you'll likely get those SubVI(s) fine and the main VI broken. But if you really want to detach each and every VI from the library, you first make sure, that your VI is working fine inside that library, then unpack the VI with readRSRC.py, in .xml remove lines like <String>Untitled Library 1.lvlib</String> in LIvi and LIds sections, then pack again to VI, move dependent SubVI(s) out of the library and open up the main VI. It may work or may not, you test it out by yourself.

So far I have left those instructions as they are, because I don't know atm, how to eliminate some steps. I believe, there should be a LabVIEW-native way to unlink the VI from the library, thus we could exclude steps 11-14. It would be easier then to automate this algorithm to process multiple VIs. Unfortunately Disconnect From Library method doesn't work on locked libraries and Open VI Reference or even Open.VI Without Refees don't work on broken VIs. There are Linker.Read Info From File and Linker.Write Info To File private nodes also, but I still have not figure out, whether they could be used for the task (any ideas?). That's why I decided to switch to LEIF formatted lib's and exe's. I found that we can bypass LEIF loader RE-ing using Save.To Buffer private node (always felt uncomfortable studying that loader, because it's rather complex). The node returns convenient RSRC with LVINLBVW block instead of LEIF, so we can easily save that into the file to deal later. I suppose, LEIF data is always translated into common resources by LabVIEW and they're in memory until the VI's are unloaded. Here's how a single VI may be extracted out of .lvlibp: extract_lvlibp_vi.vi And here's how the same may be done with the EXE: extract_exe_vi.vi To open VI inside EXE I used technique, described in this article: Passing Data Between LabVIEW Executable Reference VI and a VI Upd: see next message for the instructions. I appreciate if you find time to take a look at LEIF binaries some day, as I think you're more experienced in VI contents and internals than me. 🙂 By the way I tried readRSRC.py with LabVIEW 2020 built executable without FFF option and it worked like a charm. I can't do the same with PPL's, because that Fast File Format is forced onto them hardly and I've found no way to switch it off.

There was even a (very) short thread on LAVA: By the way I always wanted to try, but I was a bit late to it, so never seen any files to download and play around freely. Does anyone still have it on their hands? Or does it require a special licensing and thereby unavailable?

I have updated this message, as after trial-and-error takes I've got success finally! As you can see, the VI is in runnable state and behaves without any errors. My steps to reproduce: 1. Unpacked lvlibp with 7-Zip unarchiver (as I'm on Windows currently) and pulled out "2" file (LIBPLBVW resource). 2. Extracted the inner resource blocks with readRSRC.py -x -i "2" command, got 2.xml, 2_DATA0.bin to 2_DATA4.bin and 2_LVzp.bin files. 3. Unpacked 2_LVzp.bin with an unarchiver, got NI_Embedded_Library.xml and Untitled 1.vi files. 4. Extracted the inner resource blocks from Untitled 1.vi with readRSRC.py -x -i "Untitled 1.vi" command, got Untitled 1.xml and a bunch of various resource sections. 5. Renamed 2_DATA0.bin (from step 2) as Untitled 1_VCTP.bin and placed it near Untitled 1.xml. 6. Added the following text to the end of Untitled 1.xml (before the last </RSRC> tag): <VCTP> <!-- VI Consolidated Types --> <Section Index="0" Format="bin" File="Untitled 1_VCTP.bin" /> </VCTP> 7. Packed the .xml and all the resources into a single VI with readRSRC.py -c -m "Untitled 1.xml" command, got Untitled 1.vi. 8. Extracted the inner resource blocks from Untitled 1.vi (again!) with readRSRC.py -x -i "Untitled 1.vi" command, got Untitled 1.xml and a bunch of various resource sections (is done to get VCTP processed correctly). 9. Opened Untitled 1.xml and removed everything from <LIBN> to </LIBN> (including the tags as well) changed the library name extension from .lvlibp to .lvlib (between <LIBN></LIBN> tags). To wit, this line <Library>Untitled Library 1.lvlibp</Library> should be turned into this <Library>Untitled Library 1.lvlib</Library> 10. Packed the .xml and all the resources into a single VI with readRSRC.py -c -m "Untitled 1.xml" command, got Untitled 1.vi. 11. Renamed NI_Embedded_Library.xml (from step 3) to Untitled Library 1.lvlib. 12. Opened Untitled Library 1.lvlib in a text editor and altered the lib URL to point to the new location. To wit, this line <Item Name="Untitled 1.vi" Type="VI" URL="Untitled 1.vi"/> should be turned into this <Item Name="Untitled 1.vi" Type="VI" URL="../Untitled 1.vi"/> 13. Opened the VI (LabVIEW did the library reload from the new path and reported), opened .lvlib. 14. In Project Explorer untied the VI from the library w/ RMB -> Remove from Library menu option, saved the both files w/ File -> Save option. Now the VI runs fine, so it might be a time to simplify this tutorial a little 🙃 If your tools could support lack of VCTP and recreate it automagically, that would be great for sure.

I've got nearly the same result, using flarn's Resource Editor, so fixing LVSR and BDPW blocks is pretty easy. Untying from the library is no problem too. Tomorrow I'm gonna try your tools to see, how they'll go for me, and try to restore VCTP as well according to your info (manually maybe, but hope it could be automated one day). On success I could take a look at LEIF packed libraries to figure out, how to do the same. I was kind of surprised here, because both EXEs and PPLs don't have block diagrams, unless you explicitly set 'debugging' option in the build properties to get the BDs saved. Thus that 'tampered' message is absolutely unnecessary in compiled app or library, but likely there's no additional check in lvrt.dll for such a case, when the checksums don't match.

Just to clarify, gButtonsHidden field is not only those settings, that you could see in VI Properties -> Window Appearance -> Customize dialog and could manipulate with scripting properties like Tool Bar:Show Run Button etc. There are some additional VI flags also to show or hide the toolbar buttons, they're called HiddenButtonsFlags in Heap Peek (buttHid for LV2013 and earlier versions). You may investigate them on this sample VI. As you can see, the VI has Pause button hidden completely and you cannot show it with VI Properties entries, even if you set "Allow debugging" checkbox. Heap Peek displays, that HiddenButtonsFlags equals to 0x348. Honestly I don't know, why NI made that VI to have Pause button hidden, but I know, that LabVIEW stores the buttons' display state in HiddenButtonsFlags e.g. when switching to Subroutine Priority or vice versa. Sadly I have not found a way to alter all these flags from the diagram (using scripting or some other tools), so if one wants to modify the flags, (s)he has to manipulate the memory. In Heap Peeek's VI Fields there's the VI pointer in form vi=[some value]. Let's go there with any debugger of our choice. Now go to the address at the "blue" offset (I'm not saying concrete numbers, because they could change between platforms, bitnesses, LV versions, weather or who knows, what else; I was testing on LV2019 32-bit on Windows). And here we should have our HiddenButtonsFlags equal to 0x348. (The mem block is actually 2-bytes long and I'm too lazy to remake a screenshot). Now if we set that memory block to zeros, we'd have all the toolbar buttons shown (the debugging should be set earlier in the VI Properties). Such a task could even be done easier with some utility, which is able to search integers in memory and filter them in stages (ArtMoney or similar).

Mefistotelis Hi! Did you try to do the similar operation with packed library (*.lvlibp)? I mean building it from a common .lvlib with any VIs inside, unpacking it into the initial VIs and rebuilding again. I just tried and it doesn't go well. For that I especially installed LV 2014 to have the library's resources in convenient LIBPLBVW and not in modern LEIF Fast File Format. This is what I did: 1. Made a .lvlibp build with one .lvlib, having one super-simple test VI inside. 2. Unpacked that .lvlibp with 7-Zip. 3. Grabbed \.rsrc\0\RCDATA\2 file and fed it into my own extractor (written a long ago) and finally got un-CRC-ed .zip archive. 4. Unpacked .zip and got NI_Embedded_Library.xml and my test VI. Pretty the same steps, that I did many times to get the original VIs, CTLs etc. from a common EXE app. But that unpacked VI didn't want to load and reported, that it cannot find the owning packed library. Okay, then I created a .lvlib from NI_Embedded_Library.xml simply renaming it and fixing the URL path, it was referring to. Besides of that I also corrected the path in LIBN resource to point to that new .lvlib instead of the original .lvlibp. So after these manipulations the VI started to ask for some absent resource to load. So, to get it working I had to: - add VCTP block from the original VI to the unpacked VI; - replace LVSR and BDPW blocks with those from the original VI (to avoid 'tampered with password' message); - replace LIvi block with that from the original VI; - remove LIBN (to get the VI untied from any .lvlib(p)) (optional step, maybe). I wonder, if there's some easier way to get the VI(s) workable, because for some third party .lvlibp it would be impossible to do, not having the original sources (to read out VCTP at least). Do you have any insights or thoughts on it?

Maybe it would be an option for you to run the installer in silent mode (and/or) with the reboot suppression: Customize and Automate Installation of a Single NI Installer This article might be of some use also: Running a Batch File Automatically After an Installation to Access Installed Files And here's the similar thread, that points to these two articles mentioned. I also think, there's an option to not use a single LabVIEW installer, but use a bunch of msi installers by pulling them from that .exe and putting all the files into one final Inno setup .exe. You could try to run each msi with one of those flags to suppress the reboot message: msiexec /qn /i Application.msi REBOOT=ReallySuppress msiexec /qn /i Application.msi REBOOT=R msiexec /package Application.msi /norestart

I used that FP.NativeWindow property for years and it never failed for me. I was using it on Windows only though. Maybe I could test it on other platforms as well, but I never needed that. Oh, and here's one more way to invoke Heap Peek and Window Monitor (absolutely forgot about it). Another way to view Heap Peek window - NCGLaunchHeapPeek internal function. Doesn't need any parameters and returns nothing. But must be invoked in UI Thread only, else LV goes crash. Starting from LV 2015. N.B.: Both methods do not work in RTE (compiled app).

Hi! Great article, indeed. I'd like to add some little notes, that I've known of. - I saw Heap Peek in LabVIEW 2.5 already. I could propose, that it was always in LabVIEW, in any version maybe, but I can't check it right now, because I don't have LabVIEW 1.0 or 2.0 distros. - There exists another way to get Heap Peek window visible. You could use some utility to deal with applications windows, like WinSpy++ or Window Detective or any similar tool. Heap Peek is hidden window by default, but it may be displayed easily. - Those hex numbers in the upper right section of Heap Peek are the objects' addresses in LabVIEW memory, so they could be used to explore (or even modify) a single object's properties or any related data in your favourite debugger (of course, if you know, what you're looking for). - I believe, DCO stands for Data Controller Object and there's DDO also, that should be Data Display Object. I didn't study DDOs much (it's either a control or an indicator), but a DCO controls how and which data is passed through a single terminal (on BD) or control/indicator (on FP). You may find any SubVI's/node's terminal w/ Heap Peek and in its properties you should find an address of DCO assigned to it. The same is doable with controls and indicators on Front Panel. On BD DCOs are called Parameters or EFN Parameters (for CLFNs) or somehow else. On FP they're called FrontPanelDataControllers. It's easy to find them using "F" button of Heap Peek. Going to the original topic, there's "Window monitor" debugging tool also, which could be viewed with CTRL+SHIFT+D+W. It's able to display LV windows handles (HWNDs), positions, names and some other info's. Oddly nobody ever mentioned it on the forums, maybe because its use cases are very limited. It's not so convenient to use also, because its interface is very ascetic. WinSpy++ or the analogs do the similar work a way better.

I browsed through all the properties and methods of Call Library object and didn't find such scripting analogue. Seems like VI Server doesn't expose that specific property. Yes, like any other option, I mentioned above. Tried to open my DbgPrintf sample VI from another machine and all the parameters are in place. If you don't have extFuncGenNoWrapperEnabled=True and extFuncShowMagic=True in your .ini, then the option is "invisible" in the menu or on BD, but it's there. 🙂

Even when Error Checking is set to Disabled, LabVIEW still enters ExtFuncWrapper to do some basic checks before the target function is called. A few internal functions, such as _clearfp and _controlfp, are being called also. Thereby disabling "Generate Wrapper" option should make CLFN a little faster, than disabling Error Checking. You can take it like you're calling a built-in yellow node (not taking into account the called function's own speed, of course). I did not do concrete benchmarking to compare these two options. If there's an interest, I could check this out.

I checked that in LabVIEW 3.1.1 and it doesn't require the Return input terminal to be connected to some constant. I also tried LabVIEW 3.0 and 2.5 but I don't see CLF Node there, only CIN, so can't check there. Got the same in LabVIEW 4.0 (in fact it's a demo version, but DLLs are callable). I still think, there's some sort of a bug, because in LabVIEW 7.1 and 8.0 when you created that unnecessary constant on the left, connected it to CLFN and changed the Return type back to void, the VI's Run arrow becomes broken. The same applies to the wire from the constant to CLFN. But in LabVIEW 2009 and higher the Run arrow is fine and LabVIEW allows to run the VI despite oddity with the CLFN (look at the image above). This is the screenshot from LV 8.0: Might be an omission when porting to the new managers interface?..

I successfully used oglib_lvzip-4.1.0-b3 from this post, enhanced for 64-bit LV by Rolf. It always worked good for me.

Here are some "secret" INI keys related to CLFNs: extFuncGenNoWrapperEnabled=True - the most interesting one here; adds "Generate Wrapper" option to CLFN context menu (on by default). When this option is unchecked (off), LabVIEW doesn't generate the wrapper for DLL call, i.e. ExtFuncWrapper function is not called and the user's function is inlined into the VI code and called. This feature could slightly improve performance of external code communications, saving approx. 5 to 10 ms on each call. But you must be absolutely sure, that your CLFN is set correctly as no error checking is done in this case and any small mistake in the parameters leads to LV crash. There might be an indirect use of this feature, e.g. manual fine-tuning/debugging of some problematic function or a function with unclear parameters etc. When the option is enabled and extFuncShowMagic is set, CLFN is painted red. extFuncBreakOnGenNoWrapper=True - if enabled, disallows to run VI with CLFN's "Generate Wrapper" option unchecked. The Run arrow is broken and the error is stated as "Call Library Nodes with 'gen no wrapper' are not supported.". The error is detailed as "This Call Library Node is set to 'gen no wrapper'. This setting skips certain steps when calling DLLs in order to be faster, and can be dangerous.". extFuncShowMagic=True - adds some coloring to CLFNs, when "Generate Wrapper" and "Type Only Argument" options are used. extFuncExtendedOptionsEnabled=True - adds "Allow Sub-Arrays" option to CLFN context menu (off by default). I assume, it should have worked this way, but I have not found any signs that this feature is working at all. If I set "Constant" option, then a sub-array is passed into a function, else the whole array is copied and passed, no matter if "Allow Sub-Arrays" is set or not. Maybe I missed smth or it's a relic option from pre-LV2009 era... extFuncArgTypeOnlyEnabled=True - adds "Type Only Argument" option to CLFN context menu, when clicking on a node's terminal (off by default). When this option is checked, LabVIEW passes 0 (aka NULL) instead of a real value of the parameter, no matter if passed by value or by reference. When the option is enabled and extFuncShowMagic is set, the terminal is painted bluegreen (cyan). Any thoughts, what was it used for? Here's its scripting counterpart. allowPreallocsInDll=True - adds "Allow Preallocated Data" option to CLFN context menu, when clicking on a node's terminal (off by default). Did not study this one well, but it seems to not do anything or I'm wrong? Here's its scripting counterpart. callLibNodeMayHaveLVClassParams=True - if enabled, allows to run VI with LV class wire(s) passed into CLFN. By default the Run arrow is broken, when class wire is connected to CLFN. Interesting, but what can we do with it in the external code? AllowCLFNTakeSlice=True - on by default, even if absent in the .ini; appears to behave the way, that "Allow Sub-Arrays" option should do, when enabled. Let's say, some array slice (i.e., a sub-array) is passed into CLFN and the input parameter is configured as "Constant" -> "Array Data Pointer". When that .ini setting is on, no intermediate copy of the array is made, thus the called library receives a pointer to some location within the initial array. When the setting is off (AllowCLFNTakeSlice=False), then the sub-array is always copied and fed into the library, no matter if slice or not. This is the pic with some options activated: DbgPrintf.vi I also noticed that there are some private flag bits for CLFNs, e.g. extFuncVarArgs, extFuncParamsFromTL, extFuncNIValidated, extFuncTopLevelOnlyInUI. I believe, some bits should be available with scripting also. Var args feature looks interesting, but it's likely an abandoned thing, isn't it? AFAIK CLFNs never supported that in any manner. Finally some sort of off-topic, but somewhat related. Did you know that it's possible to create an input constant for CLFN's return terminal? Just set Return output as non-void and do a RMB click on the left terminal. The Run arrow is not broken and the VI runs fine. Ancient bug or intended for something? I've never seen that value being passed into external code in any ways.

I wouldn't recommend using this internal feature as it appears to be somewhat unstable. Doing a quick test I crashed LabVIEW a few times. But if you really want, you may call "Prealloc Length" (aka "PreallocLen") private property on a String control / indicator and after that "Set String Length" context menu entry is available with RMB click. BTW, that thread about fixed/bounded arrays also belongs to here: String_Len.vi

As your fork's Issues section is disabled, I'm going to ask you here. Have you had a chance to investigate the Fast File Format option, which was introduced starting from LV 2015? It's activated by default for LVLibp and can be turned on for DLL/EXE also in the build properties. If enabled, it produces LEIF resource instead of convenient LVzp, so the whole technique for extracting the resources from EXE's seems to be useless. As some dev's wrote on NI forums, LEIF is more similar to a statically linked PE or ELF file (but neither of those is used actually). There's no any insights on LEIF loader or the binaries format, so I wonder if you dealt with it in some ways.

I might be wrong, but I've never seen a LabVIEW built-in and exported function like nextafter or nexttowards in extcode.h or inside any Managers. But there's a WinAPI implementation according to MSDN: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/nextafter-functions?redirectedfrom=MSDN&view=vs-2019 So you might try to use those func's from msvcrt.dll by the means of CLFNs. Untitled 1.vi Hope, it helps somehow. Oh, and by the way, for Linux you could use libm.so and libSystem.dylib for macOS to call the mentioned functions, if you're not on Windows.

I have just tested on LabVIEW 2019 and this works fine. Here are the VI and the Snippet, back-saved to LV 2014. SHA256.vi

Okay, maybe this will make a sense?.. We want to write something into LV control/indicator (say, numeric array, doesn't matter) directly. So, convenient DS... functions are not enough for us. We need some well-established storage in VI Data Space, that is associated with our control. *HdlPtr behaves like that storage, because it's actually a memory address in VI Data Space, where we could read/write from/to and all the changes are immediately applied to our control. If you'd use the traditional method with MoveBlock and DS..., you get a handle equal to NULL. But you want to write to the control, how would you do that then? You need to tell LabVIEW, that you've created a fresh handle and want to have it applied to your control. When I've been experimenting w/ all this, my perspective was that the pointer can be passed anywhere you want, e.g. into external code, and you can do anything with it there. LabVIEW reacts to your manipulations and updates the control as you wish. In the examples everything is done on BD, but it all could be easily translated into C/C++ or another language of your choice. I might write a sample DLL to illustrate this better, but why to bother, if it may be done from the diagram?.. It's only LV-related disadvantage, that many CLFNs look bulky, in C the corresponding calls occupy few lines of code. I fact, this is what I always kept in mind, when creating this thread. 🙂 There's even some short but neat NI presentation - Improving the Performance of your LabVIEW Applications. I assume, that something could change in the memory managements, but not so drastically. DCOs/DDOs concept existed from the very first LV versions (I saw it in 2.5 already), so the basic rules to deal with these objects should stay the same. If the changes would be such significant, then you'd get a partial or even full lack of backward compatibility w/ the previous versions. Remember, modern LV still loads and runs all the versions back to 7.1. And I've personally never seen, that a generic control's pointer changes during the execution, or even that I'm unable to get it with the way described. Never liked to be wrong (who likes?), so has checked my samples on many LV versions back to 2009. Anyway, it's all not for the real projects, so even if something changes, who cares?.. 😀 As to me, I very seldomly use hacks in my work, I could count 3 or maybe 4 private property nodes for the whole term of my LV programming. The hacks are just a matter of interest, no more. Actually I'm stopping at this point, because I feel like it's a waste of time, if speak about CINs, as no any man on Earth uses CINs these days. As to CLFNs, I told the essence of what I know about the subject, so it's done. From the very LV programming days I had a question, if we could get a classic pointer to a wire or a control. Well, now ten years later, I've got the answer. It's not such a classic and not such a practical though.

I don't need a handle (i.e., TD1 **TD1Hdl) here. I want a pointer to a handle (i.e., TD1Hdl *HdlPtr). That's why I do that cumbersome SPrintf stuff. When the VI is started for the very first time, the array's handle is NULL. Later I resize the array or do some other things with it, so the handle becomes a real value. It also can change between the runs or on a new resize. Of course, I could do some logic and use a shift register to store the actual handle, but as to me it's better to do some complicated task once, rather than do it again and again in a loop. Moreover, I use the similar method not only on arrays, but also on controls, so I need a pointer to the control as well. MoveBlock dereferences the pointer and I actually get nothing to deal with later. This is my omission. I didn't even notice until you said. Numerous copy-paste operations do their evil things, when using on complex nodes like CLFNs. Fixed the VIs in my first post. Thanks. 😸 When I had a very limited test of the above VIs on LabVIEW 8.5, I noticed, that LabVIEW gives away fine (non-copied) pointer for array and the whole stuff works, but for numeric control it is no longer working. With CINs the situation is even worse. Regardless of the way how the parameters are passed, LabVIEW makes their copies and passes them instead of the originals. But under some circumstances no copies are created, e.g. when I pass the wire from Random Number VI into CIN directly instead of passing it from the control's terminal. Maybe I could try to find out what’s the matter, if possible.