Unnecessary VI error when dropping some special Controls

[Senthil_Prakash]

It creates unncesscary VI error when putting some special controls.  Say for example when dropping a Subpanel, it will ask for the VI ref to be connected makes VI error.  It can resolved as connected. 

In case of Array constant it should ask what data has to be inserted in the array when dropping itself

In the Below figure example taken as sub panel

[crossrulz]

In the case of the subpanel, you are making things more difficult on me because I would have to add the step of deleting the constant.  In the case of the array, I don't see where this will help me.  I do not like dialog boxes and I would just have to dig up the control that I want in the array anyways (type def).  And the simple dragging of an element into the array is pretty fast.  Or you can use the Change To Array that is now in the right-click menu in LabVIEW 2015.

If you give the right example, I could get behind that one.  But I do not see a reason for this.

[Senthil_Prakash]

i just given the example as constant in Subpanel it can be control also

My intention not make any VI error when we drop a control in the front panel

[crossrulz]

But it should error until you do what you actually intended to do with it.  LabVIEW should not be guessing as to what we want.

Back to the subpanel: A control would be the same affect as the constant.  Almost always I am loading a VI using the Open VI Reference and using that reference to the Insert Into Subpanel or I pass the reference into the subVI for it to load itself into the subpanel.

[Senthil_Prakash]

It might connect some default (constant, control etc).  And give the popup Please select if we dont want otherwise press escape.  The thing is when we coding in a flow unwanted errors are made is not good

[RavensFan]

I agree with Crossrulz on this one.

---

@Senthil_Prakash wrote:
 The thing is when we coding in a flow unwanted errors are made is not good

---

I'd rather have an error that forces me to fix something the way I want, then have it put something else in that makes the run arrow working, but will not allow my application to work properly.  And I might not realize that the app is not working the way I want until much much later while trying to debug some problem.  It's like the way LabVIEW makes tunnels on some structures to use the default value if unwired as the default setting for the tunnel.  Many people on the forums have come looking for help when they don't realize why their application seems to be losing data.  It is because they added a new case, but didn't wire the tunnel and they didn't realize it.  If the default was to NOT use default values, the run arrow would have remained broken until they knowingly wired what they wanted.

[AristosQueue (NI)]

I definitely agree with Crossrulz and RavensFan. But opinions on this sort of thing split across the LV R&D team.

>  The thing is when we coding in a flow unwanted errors are made is not good

Untrue for many of us. The error list is our todo list. It is the guide for what we need to do next. We *rely* upon the error list being populated as we work. Again, I know there is a split in opinion on this topic... there are many users who have begged to not have any required terminals on any node so that dropping a node never breaks the diagram. For me and others like me, that's a disasterous mode of operation.

This is a topic that requires balance because there isn't a clear right answer. In this case, it is balanced toward errors because the automagical creation of an Invoke Node is so different from any other control... it calls attention to itself so that users who are looking around for an FPTerm notice something is different.

[Hooovahh]

When I drop a subVI on a block diagram with required terminals, I wouldn't want constants to be wired up to it just so the VI isn't broken when I drop it.  This would make extra work where I'd need to delete these constants and wire it the way it should be.  Same goes for this in my opinion.  You dropped something that needs further work to make it compile without errors, so do the extra work and the error goes away.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.