Jump to content

Darren

NI
  • Posts

    604
  • Joined

  • Last visited

  • Days Won

    60

Darren last won the day on May 13

Darren had the most liked content!

2 Followers

About Darren

  • Birthday 10/02/1977

Profile Information

  • Gender
    Male
  • Location
    Austin, TX

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    1999

Recent Profile Visitors

4,747 profile views

Darren's Achievements

  1. It's because your indicator has the string as the last element in the cluster, not the first. If you change your Bundle function to have the string as the 3rd element wired in instead of the 1st, the wiring will work. I suggest you review the topic of Type Definitions in LabVIEW, where you can define a data type like a cluster in a single location, and use that type definition in all places in your code where you need that type. It helps you avoid situations like the one you describe.
  2. This utility VI is helpful for filtering out only contained controls in a right-click Affected Items array. [LabVIEW 20xx]\resource\plugins\PopupMenus\support\Filter For Contained Controls Only.vi Many of the shipping right-click plugins use this VI for the exact purpose you describe... for example, check out the source code for the Change To Array Or Element plugin: [LabVIEW 20xx]\resource\plugins\PopupMenus\edit time panel and diagram\Change To Array Or Element.llb\Change To Array Or Element.vi
  3. Relevant slide from my Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features! presentation:
  4. I assumed he was referring to non-VIPM dependencies, like NI installers which, to my knowledge, VIPM doesn't check for. But you're right, he could look for the dependencies in his pre-install VI. But maybe his package is still useful even if those dependencies aren't installed?
  5. 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.
  6. 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.
  7. It calls a private internal method, yeah. NI policy is that VIs that call private properties/methods/events are password-protected.
  8. There's also the Create NI GUID.vi in LabVIEW 2020 and later.
  9. For DQMH, the term "singleton" means that the Main VI of the module is non-reentrant. A "cloneable" module has a reentrant Main VI. So if you have a reentrant instance running (of Power and IG), then that instance will also need its own associated reentrant instance of PS class.
  10. From your description it sounds like the PS Class module has to be cloneable. Otherwise all Power and IG instances would be sharing the same singleton instance of PS Class, which I'm guessing is not what you're going for.
  11. 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.
  12. 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.
  13. Do you see similar results when running the benchmarks separately, i.e. one at a time in separate VIs as opposed to in parallel in the same VI?
  14. Hmm, I should have actually looked at the Help before doing that... our tech writer kindly pointed out that Visible Items > Error Explanation Text is already present in the Error Ring help.
  15. 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
×
×
  • Create New...

Important Information

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