LabVIEW
quick drop remove bug
Solved!
Lv2014
/Y
I confirmed this behavior in LabVIEW 2011 and LabVIEW 2015. I also tried the new "Remove and Rewire" right-click option in LabVIEW 2015. Both remove the Type Cast function and it's input, leaving the "Type" connection wired to the output. I've included "Before" and "After" pictures. I have a vague recollection of this being reported previously, with perhaps a note that this is "expected behavior" (but clearly not expected by either Yamaeda or by me) ... Incidentally, if the input is a Constant instead of a Control, the Constant will also be "removed".
Bob Schor
Yup there are several cases like this that just don't remove things the way you want. If you look at the code of the quick drop call there is some special functions that do things slightly differently. In particular I know that there are several with array functions when inserting and removing. I'm pretty sure inserting the Delete From Array never does what I want.
Type Cast is an intersting one, because the wires you want to wire after a remove, are going to be of differing data types. So in your case if I was a program trying to remove the function I might try to match up the double, input with the double output, so I can see why this function might not do what you want.
Also not sure if complaints like these should be posted on the QD community.
https://decibel.ni.com/content/groups/quick-drop-enthusiasts
Couldn't edit my last post, I made a thread in the linked QD community.
I don't know when/if I'll be able to add tweaks to fix these issues. For now, a workaround for the Type Cast issue...assuming you have a constant wired to the middle terminal, if you drag a selection box around both the Type Cast and the constant, then do Ctrl-Space-Ctrl-R, it will create the wiring as you desire:
At some point in the recent past (2013 or 2014 maybe?) I added some logic to Remove and Rewire to make sure that nothing in the selection list (like a constant) is a candidate for rewiring, and instead is always removed, along with the selected function(s).
Do not try to find excuses... 🙂
What the CSCR shorcut does is connecting identical types:
when it should connect input to output (not the type!). It just happens that for the Type Cast function, the current logic is going to do the "wrong" thing most of the time.
Not always though:
@natasftw wrote:
It's a bit harsh to tell the guy admitting it behaves strangely to not make excuses.
Why would you ever typecast a datatype into itself? That's a rather worthless test case. In any useful case, it'll behave in a way we wouldn't expect. Darren agrees. He provided a workaround. If his time is short, I'd rather him focus on something that I'll use a lot more often than the quick drop shortcut for removing a typecast (even though I'd agree the current behavio is buggy).
I know the logic is to try and match data types, that's probably the culprit here. In this case, though, i'm converting a U32 to an Enum, which is basically the same datatype.
However, in the case of Type Cast, i cant see any situation where you'd want the Type to connect to the output.
I'll remember the work around, but in this case it wasn't feasible as the constant was also connected to other functions.
/Y
The same behaviour can be seen with Format into string, QD removing the block connects the output to the constant and not the Input string. LV2011
/Y
