Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by dadreamer

  1. Yeah! LabVIEW 2020 64-bit - RD doesn't work for strings as it should do. Even when the VI is unloaded, LabVIEW still holds some memory allocated and never releases. No tracks of it on NI forums. Anyone with internal access to the list?
  2. AFAIK i386 is for Windows 32-bit and wx64 is for Windows 64-bit. Following this logic u should be for Linux and m for macOS, but I'm not 100% sure. I'm just saying, what I saw when browsing through a number of CINs with their PLAT sections.
  3. You might try loading macOS LV version into debugger, because it has more debug symbols unstripped unlike Windows and Linux versions. As I recall I was able to read out the rest of the parameters and their types just by browsing the code in IDA. It's mostly about old LV versions before LV 2009. Check LVSB and PLAT resource sections (and maybe LIsb for external subroutines), if you're going to study how CINs work. There are Rolf's articles also, that could help you to put all the pieces together: https://forums.ni.com/t5/LabVIEW/What-happened-to-CINs-And-how-else-can-another-language-wo
  4. Try to use this VI to get your window on top of the world: Set Calling VI Wnd Topmost & Active.vi This is the thread, where it came from. You may use it this way: wnd_test.vi Or you may invoke the SubVI at strictly specified intervals, you decide.
  5. 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' secti
  6. 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 t
  7. 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.
  8. 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.
  9. 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>
  10. 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 u
  11. 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?
  12. 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 block
  13. 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
  14. 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
  15. 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 extrac
  16. 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 w
  17. 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).
  18. 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 H
  19. 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. 🙂
  20. 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.
  21. 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
  22. 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.
  23. 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 don
  24. 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
  25. 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 load
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.