Jump to content

Darren

NI
  • Posts

    627
  • Joined

  • Last visited

  • Days Won

    68

Posts posted by Darren

  1. Can you use the private UnattendedMode property in your post-install VI? The searches would still take place, but at least you wouldn't have to see the dialogs?

    Could you replace the calls to possibly-missing VIs in your code with dynamic calls? This would work if there were only a few calls.

  2. For a regular library (.lvlib), opening a reference to it (via the 'Library.Open' method) will not bring member VIs into memory.

    For a class (.lvclass), opening a reference to it (via the Library.Open method) will bring all member VIs into memory. There's no way around this behavior that I know of.

    • Like 1
    • Thanks 1
  3. 27 minutes ago, X___ said:

    I do have LongPathsEnabled set to 1 on my Windows 10 Pro system:

    Individual apps have to include long path support in order for this setting to have any effect. And LabVIEW 20xx currently has not added this support. Please kudo this idea (if you haven't already) to increase the visibility of the feature request with LabVIEW R&D.

  4. FYI to anyone using Bean's VIs. I was successfully using them in an application, but they had a peculiar side effect. Whenever another application on the system (G-Force) was in full-screen mode, the LabVIEW application windows were non-responsive to mouse clicks. If I switched G-Force out of full-screen mode, the LabVIEW windows started behaving properly again.

    It took me a while, but I figured out that in order to fix the issue, I needed to add another call to 'AttachThreadInput' at the end of Bean's code IF AttachThreadInput had been called earlier. In Bean's code, the 'fAttach' parameter is set to '1' to attach the thread. If you do this, you then need to call AttachThreadInput again at the end of the code, but with an 'fAttach' value of '0' to detach the thread. When I made this change, my application remained responsive to mouse clicks even when G-Force was in full-screen mode.

    • Thanks 1
  5. 9 hours ago, thols said:

    Thanks Darren, I didn't know that. Maybe because that is also not in the help.

    I updated the Bug report to mention that this should be in the help. Also, I talk a lot about use cases for the Error Ring (including mentioning several of the points I brought up in this post) in my What To Expect When You're Expecting an Error presentation here: http://bit.ly/dnatterrors

    • Thanks 2
  6. I have reported the documentation issues (both the 'page not found' error, and the suggestion about placing error rings in case structures) to R&D as Bug 1413653.

    12 hours ago, thols said:

    Error rings are so large I am tempted to put them in a sub-VI just for that reason.

    Don't forget you can deselect Visible Items > Error Explanation Text if you need your Error Rings to be more compact:

    image.png.a91a6f0925b89b326e63b7a18d35eaf8.png

    • Thanks 2
  7. On 2/27/2021 at 12:37 AM, Jim Kring said:

    If you have a VI reference at run-time, can you tell whether it is a static VI reference (via Static VI Reference node) or a dynamic VI reference (opened with the Open VI Reference) function, since the VI lifetimes (and lifetimes of references created within them) are managed differently by LabVIEW.

    I checked with LabVIEW R&D, they said there is no way to determine this information in G code.

    • Like 1
    • Thanks 1
  8. (I'm not at a machine with LabVIEW at the moment, so I apologize if I'm not remembering some of this correctly)

    I see that the static VI reference in your screenshot does not have the little orange star in the corner, which means it's not a strict reference. If you were to wire that reference into a Call By Reference function, you wouldn't see a connector pane pattern. So as your diagram is currently implemented, the types of those wires are identical since the static VI reference wire doesn't contain any type info. Isn't that right? Can you right-click the static VI reference and select something like "Include Data Type"?

  9. 2 hours ago, drjdpowell said:

    It's the inconsistent state that is the problem, where the by-value bit is inconsistent after the by-ref bit is changed in parallel.   That doesn't always happen; sometimes either the value or the reference bit never changes.   But one needs to be aware of this issue.

    Dr. Powell pretty much gave my answer (stated more eloquently :) ). It's something to look out for when branching wires... by-value data is now a copy, while by-reference still refers to the same thing. Be aware of that when you start mixing by-value and by-reference inside class member data.

    • Thanks 1
  10. 2 hours ago, Aristos Queue said:

    But some places have coding conventions that require no spaces in the name -- it's easier to use git with such files.

    Probably best for a new thread, but I'm curious about why you claim it's easier to use git with files with no spaces. In my (admittedly non-advanced) dealings with git I haven't seen any problems with files with spaces. Now repo names with spaces? Yes, that has caused issues. :) But I've been working with very large codebases in git containing VIs and project libraries/classes with normal naming conventions (including spaces) and have had no issues.

  11. 34 minutes ago, Neil Pate said:

    I am trying to use your HMAC - SHA256 to generate a token to allow me access to an Azure Iot hub. I have a snippet of c# code that works fine and I am trying to translate into LabVIEW but not having much luck.

    I remember having to figure this out when generating tokens for the LabVIEW Cloud Toolkit for Azure. I remember that there was some weird stuff I had to figure out, but I've long since forgotten how I did it. On the bright side, the toolkit is open source, you can browse through the source code here to see how I did it.

    • Like 2
  12. Yup, Quick Drop itself (along with several other G-based LabVIEW features) uses Global Data Get/Set. Standard disclaimers apply (private methods are not documented or supported by NI), but these should get you what you need. I agree with Yair that you need to make sure to namespace your data appropriately so it doesn't potentially collide with other Global Data.

    • Like 1
×
×
  • Create New...

Important Information

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