Jump to content

LogMAN

Members
  • Content Count

    555
  • Joined

  • Last visited

  • Days Won

    54

Everything posted by LogMAN

  1. You are right, I haven't thought it through. Source access is required to recompile, which makes any encryption/obfuscation/protection annoying to reverse engineer at best.
  2. Here is a KB article with information about the design decision of password protection: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LvFSAU Not sure why strong encryption would be impossible. One way to do that is to store a private key on the developer(s) machine to encrypt and decrypt files. Of course loosing that key would be a disaster
  3. Perhaps I'm missing something, but the way this works is when you move up one folder, that folder is "selected", so pressing OK will open the folder again. What makes it confusing is that the filename (and not the folder) is highlighted active (blue and not gray), so a user might think that pressing OK will confirm the filename, which is not the case. To my knowledge there is no way to change this behavior in Windows (the dialog is not actually part of LV). By the way, even if you deselect the folder, it will still enter the previous folder, which is certainly not intuitive to most users
  4. The file still exists, only the link above is dead.
  5. Why stop there? Magic Delay.vi
  6. I'm no expert with CLFNs but I know this much: LabVIEW does not have a concept for unions but you can always pass an array of bytes or a numeric of appropriate size and convert later. Just make sure that the container is large enough to contain the largest member of the union (should be 64 bit from what I can tell). Conversion should be simple enough for numeric types but the pointer requires additional work. Here is some information for dereferencing pointers in LabVIEW (there is a section about dereferencing strings). https://forums.ni.com/t5/Developer-Center-Resources/Dereferencing-Poi
  7. It creates a headless instance, so no dialogs. I haven't checked the unattended mode flag, but I'd assume it is set by default 🤷‍♂️
  8. You could run the build in its own context, which (to my knowledge) does not save any changes unless option 0x2 is active (see Wiki for more details). Application class/Context.Create Local Host App Instance method - LabVIEW Wiki
  9. Thanks, this is very helpful. One more reason to replace the built-in functions with your library.
  10. I recently stumbled upon this issue while debugging an application that didn't handle JSON payload as expected. As it turns out, Unflatten From JSON breaks on NUL characters, even though Flatten To JSON properly encodes them as ("\u0000"). I have confirmed the behavior in LabVIEW 2017, 2019, and 2020 (all with latest service packs and patches), currently waiting for confirmation by NI. Workaround: Use JSONtext
  11. Got the same issue in LV2020 SP1 The page exists, it is just incorrectly linked
  12. Yes it is, both ways. I'm glad you like it There is a new release which adds support for composition of maps and sets. Here is an example of what you can do with it: This is actually a very smart way of doing it. My library takes the keys and values apart into individual arrays. A key-value-pair is certainly easier to work with...
  13. It's probably not a good idea sharing DBC files publicly. That said, your database loads perfectly fine for me. Perhaps your XNET is outdated? I have no problems with XNET 19.6
  14. Welcome to LAVA 🎉 Not sure where you read that, here is what the LabVIEW help says: I don't see the benefit. Your projects will take longer to load and if the compiled code breaks you can't even delete the cache, which means you have to forcibly recompile your VIs, which is the same as what you have right now.
  15. What you describe is called a fork Forks are created by copying the main branch of development ("trunk") and all its history to a new repository. That way forks don't interfere with each other and your repositories don't get messy.
  16. If you are leaning towards Mercurial you should visit the Mercurial User Group: https://forums.ni.com/t5/Mercurial-User-Group/gh-p/5107
  17. Git I don't hate it - the centralized nature of SVN simply didn't cut it for us. No. It was my decision. Pro - everything is available at all times, even without access to a central server. Con - It has too many features, which makes it hard to learn for novice users. Only when I merge the unmergeable, so anything related to LabVIEW 😞
  18. Please keep in mind that it is only my mental image and not based on any facts from NI. Perhaps both. If we can understand the current behavior it is easier to explain to NI how to change it in a way that works better for us. Here is an example that illustrates the different behavior when using indicators vs. property nodes. The lower breakpoint gets triggered as soon as the loop exits, as one would expect. I have tried synchronous display for the indicator and it doesn't affect the outcome. Not sure what to make of it, other than what I have explained above 🤷‍♂️
  19. Disclaimer: The following is based on my own observations and experience, so take it with a grain of salt! The user interface does not follow the dataflow model. It runs in its own thread and grabs new data as it becomes available. In fact, the UI update rate is much slower than the actual execution speed of the VI -->VI Execution Speed - LabVIEW 2018 Help - National Instruments (ni.com). The location of the indicator on the block diagram simply defines which data is used, not necessarily when the data is being displayed. In your example, the numeric indicator uses the data from the
  20. A Static VI Reference is simply a constant Generic VI Reference. There is no way to distinguish one from another. It's like asking for the difference between a string constant and a string returned by a function. The Strictly Typed VI Reference @Darren mentioned is easily distinguishable from a Generic VI Reference (notice the orange ⭐ on the Static VI Reference). However, if you wire the type specifier to the Open VI Refnum function, the types are - again - indistinguishable. Perhaps you can use VI Scripting to locate Static VI Reference
  21. Sure thing, it's also good to know there is a thread like that - first time I've head of it 😮
  22. The number to string functions all have a width parameter: Number To Decimal String Function - LabVIEW 2018 Help - National Instruments (ni.com) As long as you can guarantee that the number of digits does not exceed the specified width, it will always produce a string with fixed length (padded with spaces).
  23. I discovered a potential memory corruption when using Variant To Flattened String and Flattened String To Variant functions on Sets. Here is the test code: In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW. Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off: Here is the translation: 0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK 0x0073 - Data type (Set
  24. There is a VI in OpenG LabVIEW Data Library that does this for you. I took this as a challenge and added two VIs to my library on GitHub - https://github.com/LogMANOriginal/LabVIEW-Composition Decompose Map extracts variant keys and values of variant maps Decompose Set extracts variant elements of variant sets I have successfully tested these VIs with various different types, but there could still be bugs. Let me know if you find anything. I strongly discourage using these in production!
×
×
  • Create New...

Important Information

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