Properly Insert "Delete from Array"

[P@Anand]

When I Right click a wire and tried to insert a "Replace array subset" its getting inserted properly but the same doesn't work with the delete from array and I had lot of instances where I have to insert a "delete from array". I am proposing this after searching this forum but If already proposed then I'll try to give Kudos for that.

So without broken wire it would be nice to insert a "Delete from array" function.

[jcarmody]

The position of your mouse pointer affects how the node is inserted.  It works fine if you invoke the insert when your tool is positioned as shown below.

If your tool is on/above the wire you'll get what you showed.  That this is a pain in the neck is another discussion.

[P@Anand]

Yes I checked it and it works but still for the other case (Replace array subset) it gets inserted whatever the tool may be. I would still stand to fix it so that no more discussion required. 🙂

[parthabe]

Hi folks,

There seems to be a lot of inconsistencies if you start testing for the 3 Array functions (Insert, Replace & Delete) across different datatypes.

• Unlike jcarmody said, it works for Numeric datatype ( tested for DBL & I16) always, whatever the tool may be (works for even Text tool).
• For Bool array, inserting a Delete from Array function or, for that matter, an Insert Into Array function with Arrow cursor, always breaks the wire (but Replace Array Subset function gets inserted properly). But, for Str array, it works sometimes, it breaks sometimes.

So, this problem is not only present for Delete from Array function, but could be for other Array function(s) as well. 

[AristosQueue (NI)]

It's not inconsistent... it just isn't customized. 🙂

The same algorithm runs insert for all nodes -- it tries to match terminals until it finds a good type match, and it happens to give priority to outputs than to inputs (because that minimizes the number of coercion dots that might appear). So on Delete, it matches the second output (not match exact, but array is close enough, and is a tie in terms of type distance + physical distance with the top terminal... the physical distance element is why mouse position with respect to the wire maters... that addition was made a few years ago because there are nodes where both top and bottom insertion is equally desirable based on conditions). Then it tries to match the input and none of the types match -- because Delete defaults to an array of numeric. Finding no type match, it uses the most aligned terminal with the chosen output.

Very consistent, but not what you want. We would need to add custom code specific to inserting this particular node.

I've struggled over the years to figure out a way to have a generic insert algorithm that takes into account the various special cases and have come up empty. I -- and others on R&D -- have coded a few exceptions in over the years, just never got around to these.

I mention all of this in case anyone has suggestions for a generic algorithm without knowledge of the specific workings of the node being inserted that would work to get more nodes inserting correctly than we have today.

[X.]

It is not just insert. Replace suffers ftom the same issue.

If I try to replace this "Insert Array Subset" function by a "Delete from Array" function, you would think that mouse position shouldn't matter.

It doesn't, but the result is bogus:

===> Replace by "Delete from Array" ====> 

Hint: the index should stay an index (Super Hint: in particular when the object has nothing to do with an numeric).

[P@Anand]

This is similar to replacing a VI with different connetor terminals. I wouldn't call this as a bug instead I would call it a "Feature request". This could be suggested seperately.

[X.]

Sure, except this is not a VI.

I think it is related to your suggestion, which is why I did not post it as a separate thread.