Jump to content

Darren

NI
  • Content Count

    560
  • Joined

  • Last visited

  • Days Won

    45

Posts posted by Darren


  1. Oops, looks like I missed when this feature went in. As AristosQueue mentioned in a reply to your Idea Exchange post, you can use the Dependencies > Missing Dependency Names and Dependencies > Missing Dependency Paths properties of the GObject class in LabVIEW 2015 and later. Can you verify that these properties give you want you need, and I'll close out the Idea Exchange post as Already Implemented?

    • Like 1

  2. Unfortunately there is currently (as of LabVIEW 2019) no comparable functionality to the Missing VI Name/Missing VI Path from subVIs for typedefs, nor is this functionality going to be in LabVIEW 2020. I suggest posting this request on the LabVIEW Idea Exchange. It would be a useful feature for tooling like what you've described.


  3. 19 minutes ago, Porter said:

    Are you talking about right click during edit time or during runtime?

    Does this explain the random right click of doom that freezes LabVIEW after right clicking on an item in project explorer?

    He's talking about edit-time panel and diagram menus and run-time diagram menus that are implemented as right-click plugins.

    This bug fix does not affect right-clicks in the project window.

    • Thanks 1

  4. 6 hours ago, Yair said:

    Darren, any chance of getting the All Supported Properties property of the Property class (i.e. the property node) to actually return all the supported properties for the current class of the property node, including all of the nested ones?

    As it is today, that property only returns the top level properties (so it would show a Label property if the node is linked to a class inheriting from Control, but not all the subproperties coming from the Label class).

    If that's too hard for support reasons, maybe at least adding a new property which will actually return all of them?

    This is a good idea. I suggest posting it to the Idea Exchange.


  5. 3 hours ago, ShaunR said:

    I've got it in 2019 but not in all the other versions. Is there a separate test install for each version?

    Yes, it's a LabVIEW Toolkit, which means you have to install it separately for each LabVIEW you have. Here's the download page where you can get whichever version (and bitness) toolkit installer(s) you need:
    https://www.ni.com/en-us/support/downloads/software-products/download.labview-vi-analyzer-toolkit.html

    • Thanks 1

  6. I've written tools before that involved scripting probes onto wires. The way I facilitated communication between the executing probe and the scripting framework was through a named queue. I could pass the name of the probe VI (which ends up being the name shown in the first column of the Probe Watch Window) to my scripting framework. Meanwhile, my scripting framework had used the "AttachProbe" method of the Wire class to create the probe. This method returns a Probe reference, which you can then use with a property node to read the "ProbeVI" property, which gives you a VI reference, and you can read the VI Name property to match up which Probe VI got attached to which wire.

    Note that the "ProbeVI" property is private, so you'll have to do some digging on how to enable private properties/methods if you haven't already. 


  7. 40 minutes ago, JKSH said:

    does anyone know whether the new official VIs are just wrappers for the Hidden Gems VIs? Is it OK to keep using the Hidden Gems VIs going forward?

    The official VIs are different implementations. I imagine they're faster, since their implementation is simpler (they just wrap Spreadsheet String to Array and Array to Spreadsheet String). Also the new VIs have the standard connector pane and official icons.

    You shouldn't have any issue continuing to use the hidden gems if you prefer those.

    • Thanks 1

  8. Just now, Daklu said:

    My apologies if I misrepresented what you said.  Can you elaborate on why you recommend against using XControls?

    No problem, I just want to make sure people know the difference between "Darren the G programmer says _____" and "Darren the NI employee says _____".

    In my "Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features!" presentation, after I clarify that I'm presenting my personal opinion and not an official NI position, I contraindicate XControls because of numerous stability issues I've seen with them in large applications over the years. You can see my slides and watch a recording of the presentation here: http://bit.ly/dnattlvhooks 

    • Like 2

  9. You don't need to type cast to string when using maps. Change the keys in your Map code to be U64s instead of strings and let's see the benchmarks. Type casting is expensive. One of the benefits of using the map data type is that you no longer are forced to use strings as your keys.


  10. On 5/29/2019 at 10:55 PM, Daklu said:

    I am under the impression XControls have more or less been relegated to the rusty nails bin. I know I've seen NI employees recommend against using them in presentations. 

    One of those employees is me, but I am always clear when I discuss this topic that my recommendation against XControls is my personal opinion and is not an official NI position.

×
×
  • Create New...

Important Information

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