Jump to content

Darren

NI
  • Content Count

    539
  • Joined

  • Last visited

  • Days Won

    40

Posts posted by Darren


  1. 2 hours ago, flarn2006 said:

    However, strangely, I haven't found any methods/properties that do anything specific to build specifications. Maybe I'm looking in the wrong place though.

    Yeah, I'm not aware of any. The App Builder API (vi.lib\AppBuilder\AB_API) provides most of the functionality you would need to programmatically modify build specs. I talk about it briefly in my Hidden Gems presentation: http://www.ni.com/hiddengems


  2. 2 hours ago, LogMAN said:

    (standard disclaimer, unreleased software, not an official benchmark, etc. etc.)

    I just tested dragging selection boxes on that diagram in LabVIEW 2018 and in the latest LabVIEW 2019 build. Selection rectangles draw significantly faster in 2019. Window scrolling while dragging a selection box is also much faster.

    For reference, my dev machine is Win7-64, 16 GB RAM, E5-1650 3.5GHz.


  3. On 1/14/2019 at 8:45 AM, hooovahh said:

    So does that mean that this deprecated function is still semi-supported?  I assume it was deprecated for a reason, is it unstable under any known circumstance?

    If I recall correctly, it was deprecated because the current property is more explicit about how you're assigning the property name (ID, short name, long name), whereas the deprecated property was more ambiguous (you could wire in any of them I think). But to my knowledge, there's no problem using the deprecated property. When I update the VI Server Rename plugin, I'll make sure to only call the deprecated property if there's a period in the specified property name.


  4. Thanks for digging this up, Paul. I got it to work for dotted properties of multiple levels (so not only Label.Text, but also things like Terminal.Wire.Terms[]). I'm going to try to update the VI Server Rename plugin for Quick Drop to allow setting dotted properties by using this deprecated property. (?)

    • Like 1

  5. 3 hours ago, hooovahh said:

    There are private events on the tree for Item Close? and Item Open? which is a filtering event and allows you to discard the open and close.  You need the super special private special stuff INI to access these.  Then I'd recommend turning that INI off after.

    From what I can tell, the Item Close(?) and Item Open(?) events are not private. Maybe they were in a previous LabVIEW release?


  6. 1 hour ago, Tom O said:

    For Darren, if you try to wire from the constructor, you cannot find the terminals.  It is only if you create another object and try to wire it to the constructor that you can connect to the terminals (or if you try to wire one of the other terminals on the constructor to the hidden ones).  Also, their vertical location is in the center of the constructor, so if you are trying to connect to the top, it will appear that they don't exist.

    Ah, there's the piece I was missing. Thanks for those details.

    I have filed CAR 711518 on this issue. I agree that it is a significant usability concern that it is so easy to wire to that null reference terminal, have code that doesn't function correctly, and not have an indication as to why.

    • Like 1

  7. 19 minutes ago, ShaunR said:

    It does surprise me. I would have thought an entry for VI Type would have been added to the enum.

    Yeah, I think the explanation given to me was that the contents of the .vim file on disk are no different than the contents of a .vi file on disk. So since it's technically not a different file type, they thought it didn't warrant a new enum entry. Kinda like how there's not a "Template VI" entry in the list since .vi and .vit are the same type on disk. I may be misremembering though so don't take this as the official answer.

×
×
  • Create New...

Important Information

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