LabVIEW
String Ctrl-C/Ctrl-X Bug
I would call this "Expected Behavior." I've always expected LabVIEW to act this way since it always has. This may be less than optimally aligned with paradigms in other applications (so is Zoom - but, you know that too.) I would be willing to bet that the "Other" applications you tried this with do not follow conventions prevallent while LabVIEW integration to the clipboard features were under development.
I'm not convinced that a radical change to align with another paradigm for clipboard operations would offer more benefits to developers than frustrations. Of course, I still look for Window>>VI Hierarchy sometimes so, this might just be my problem, not a common opinion.
You can always float the thought on the Idea Exchange...
> I would call this "Expected Behavior."
With such low expectations you must be one happy fellow. 
> ...operations would offer more benefits to developers than frustrations
I should probably pick on AQ here since he has expressed a similar world view a few times recently and gets paid the big bucks to hear us complain, but Jeff queued it up so here goes (not picking on Jeff BTW). There are three seats at the table, the folks at NI who develop LV, folks inside and outside NI who develop software using LV, and the folks who use the software we develop with LV. The first two groups are heavily overrepresented in discussions around here, and unless you sit in the third seat once in a while it is easy to neglect them. When I get spun up it is usually trying to make the voices of the third group heard. When I really want NI to do something it is often to make my code better for the users, not to make my life easier as a developer (although the two tend to go hand in hand).
LV has caused plenty of pain to my backside area in the past couple of decades, and yet I still come back for more. If this "behavior" was an issue of causing pain to developers, my queue of pet peeves is pretty long and there is always room for one more.
The issue here IMO, is that this behavior causes annoyance, confusion and frustration to users of code written in LV. They may not have chosen LV, or even know what it is. They want a piece of software that works. When they see behavior like this that is outside the norm, they do not care that it happens to be the way LV is, they want it fixed. So yes, I have to put custom handling in all UI strings to properly handle basic cut/copy/paste operations, and not just this behavior.
So I have to be Maude Flanders around here, "Won't somebody please think of the children!".
This is a BUG!
I am always curious in these situations. Is it a lack of code that causes this (unhandled case), a byproduct of other code, or the intended result of code that is in there. It feels like this was done on purpose, the user pushed a key, we have to do something. The grey area is what should the clipboard contain. Most software I have tested leaves the clipboard alone with an empty cut/copy, I could see the desire to clear the clipboard in that case. That is kind of what I asked for isnt' it. What I didn't ask for is a letter x or c.
@X. wrote:
Couldn't say it better, and BTW, just in case, my previous post was intended to be humorous.
For NI's eyes only: look for "X_Bug_Report" tags for CARs like this one waiting to be filed. Thanks.
I'm on your side, too. It is definitely UNexpected behavior, as far as the user is concerned.
Now if it never followed the ctrl-c/ctrl-x convention in the first place, that would be a different story...
