Darren

2 hours ago, LogMAN said:

Send them this VI for reference: https://forums.ni.com/t5/LabVIEW/Very-complicated-labview-block-diagram/td-p/3187507

(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.

19 hours ago, flarn2006 said:

Does this mean its deprecated status will be removed?

Not in 2019. But we will look into consolidating the API in 2020 so the non-deprecated method is able to set dotted properties like the deprecated property can.

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.

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. (?)

You can also use Quick Drop Replace to replace multiple items at once.

Select all the controls you want to replace > Ctrl-Space > Type name of new item > Ctrl-P to replace them all.

I had no idea this existed. I will look into it.

Correct. Scripting does not support setting dotted properties.

+1 for installing shared dependencies in vi.lib with VIPM packages. Makes this sort of thing much easier to manage than having each project have their own copy of the reuse code.

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?

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.

I'm not sure how you got into this state, I don't see the hidden terminals in scripting. And if you delete those wires, there's no way to get back to the hidden terminals. Also, I got a DWarn when I copied your snippet into my diagram. So I'd chalk this up to some weird corner case/corruption and move on.

There's a private 'Operate Menu Dismissed' event that may help in this situation.

Can you attach a simple write VI and read VI that demonstrate the issue?

51 minutes ago, the_mitten said:

Huh. Yeah, I didn't expect this. Doesn't this suppose that the user hasn't changed the displayed label text for the subVI?

It's impossible to change the label text of a subVI. That's why this works.

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.

2 hours ago, jacobson said:

I'm not sure what the best way would be to figure out whether the subVI is a VIM.

It may surprise you that this is the best way:

You can also press Ctrl-Shift-E from an open VI to select that VI in the project explorer.

All of the functionality provided by the Icon Editor UI is also available programmatically with the LabVIEW Icon API, available here:

[LabVIEW 20xx]vi.lib/LabVIEW Icon API

This API, along with many others, is described in my Hidden Gems in vi.lib presentation.

There's more where that came from.

It's not a G-based dialog, so to my knowledge, there's no way to launch it programmatically.

I wrote this nugget a long time ago, but the tips are still applicable:

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-30-2006/m-p/434181

rolf's explanation is the best discussion of the string range rationale I've seen:

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-03-09-2009/m-p/867644#M392955

Yes, that's right.