Jump to content

When will the "can't drop this VI in that empty space in the diagram" bug be fixed?

Recommended Posts

The title is made up, but explains what I have been experiencing for years, hoping that it would be fixed in the next version, but it never has, so I am starting to suspect nobody is caring or possibly maybe nobody even noticed it?

Anyway, the symptoms are:

when I drag a VI (from either a palette or from the icon of an open VI) into a target VI's diagram, I am frequently encountering this odd and annoying¬†ūüöꬆsymbol where my cursor is (it's not red and it is slanted the other way, but this is the closest emoji to the real thing I could find), instead of the "androgynous" cursor (a mix of¬†‚ôÄÔłŹand¬†‚ôāÔłŹ) which tells me that I am going to copy that object where the cursor is.

I would move the cursor around, seeing a¬†ūüöꬆwherever I go, until¬†I would fleetingly¬†grasp a cursor with the + index (the "androgynous" cursor)¬†over some random location, and then, painstakingly try to go back to that region to find the sweet spot (pixel really) where I am able to drop the VI. Of course, once dropped on the diagram I can move the VI anywhere where I was forbidden to drop it during my initial attempts.

That's got to be the most annoying bug in a graphical programming environment ever...

Am I the only one to experience this?

I am using 2019 SP1 64 bit, but that has been around for several versions already.

Link to post
Share on other sites

I have never seen such behavior in any version of LabVIEW. That said, I use 32 bit. Perhaps it's specific to 64 bit?

If Windows scaling is enabled, try disabling it. I had strange behavior because of that in the past.

Link to post
Share on other sites

I don't follow you and may need a video to understand.  Are you saying you can't drag an item from the palette onto the block diagram?  I've never seen what it sounds like you are describing.

Link to post
Share on other sites

Here is the video illustrating the symptoms.

Of course the demo effect wants that the first time I try to drop the subVI, the cursor looks fine (I had just verified on a brand new VI that the symptom appeared right away, and after I went through the recording hoops, I had to "work" for it to show up), but a brief excursion with the cursor over the project (from which the subVI came, so indeed I could not drop it again in there) was enough for the cursor to turn back to the "forbidden" icon.

I am not sure that is very visible in the video, but there is a little bit of a "stuttering" and you can usually very briefly see the arrow+ cursor alternating with the forbidden icon.

The bottomline though is that I cannot drop the subVI in most of the virgin diagram and have to actively search for allowed drop zone.

I have come to get used to it now, but it is definitely getting old and a productivity hog.


Link to post
Share on other sites
9 hours ago, LogMAN said:

If Windows scaling is enabled, try disabling it. I had strange behavior because of that in the past.

No scaling enabled that I know of. I am using a VM in Parallels Desktop running on a MBP,  but I would be surprised it is the root cause.

Link to post
Share on other sites
9 hours ago, Neil Pate said:

How frequently? I must say I cannot recall seeing this, certainly not regularly enough for it to be a nuisance. Can you post a video?

Frequently enough that in my drive to make this world a better place, I decided this was a worthy campaign to galvanize the crowds for.

Link to post
Share on other sites

Thanks for the video, definitely never seen that.  I'd suspect it is an interaction with Parallels, like LabVIEW losing track of what you are under as you transition to other systems.  No idea.

Link to post
Share on other sites

Never seen this kind of thing running on plain metal across many versions of LV. I do often lose my right Control key though if I use VirtualBox as I think that key is reserved for other stuff.

Link to post
Share on other sites

I agree with @hooovahh. This is likely an issue with Parallels. I don't have a VM to try this, but I assume that your cursor leaves the VM for a brief moment (the "stuttering"), which causes this strange behavior. Parallels probably buffers the cursor info and restores it in a way that is incompatible with LV.

Does Parallels allow you to "capture" the cursor, so that it can't leave the VM without pressing some master key? I can imagine this fixes the issue.

Link to post
Share on other sites

Parallels has a few bugs up its sleeves too, so I am willing to lean toward that conclusion too considering that no one seems to have observed this.

Is anyone using Parallels Desktop in "Coherence" mode and observing this phenomenon? There is no Windows' real estate per se in this mode, each Windows app's window appears as a regular macOS one (with the Windows style though), so I can't really imagine that the OSes could be mislocating the cursor... but this is all beyond my technical knowledge to really ponder.

Thanks for looking into it though.

Link to post
Share on other sites
  • 3 weeks later...

I remember some similar issues in the past on plain Windows. Not exactly the same but it seemed to have to do with the fact that LabVIEW somehow didn't get the Window_Enter and Window_Leave events from Windows anymore or at least not properly. And it wasn't just LabVIEW itself but some other applications started to behave strange too. Restarting Windows usually fixed it. And at some point it went away just as it came, most likely a Windows update or something.

So I think it is probably something about your VM environments cursor handling that gets Windows to behave in a way that doesn't sit well with LabVIEW.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By wuuuuuud
      Well, in my project I *have to* get data from another program via the clipboard. And the data transferred could be as large as several MB. When another program send the data to the windows clipboard, the whole labview program will stuck for several seconds or minutes,depending on the data size. Meanwhile, the memory Labview using increases slowly in the task manager. This occurs every time, no matter whether a VI is running or not.
      So, I guess the Labview is monitoring the clipboard changes and always trying to parse the clipboard data to the format of a FP control or something else, which could be time-costly.I'd like to know if anyone here have experienced the same issue or if there is another possible reason or solution for the stuck?
    • By John Lokanis
      I have been seeing some weird behavior and was wondering if this is a known issue or if I have discovered something new.
      I have two projects that share several libraries and classes.  One is a client application and one is a server.  In order to test my code, I need to open both projects at the same time and run the main VIs.  When I open the projects, the common libraries and classes are locked and I cannot edit them.  So far, this appears to be normal.  Where it gets strange is when I close one of the projects.  If I have run the VIs to test something and then stopped them, closing the owning project of one of the main VIs DOES NOT cause the VI to also close.  The correct project name is still indicated in the VIs window (lower left) and the project is clearly closed but the VI is still hanging around.  The second thing that is weird is the common libraries and classes remain locked. Even closing the other project and returning the to the start-up screen does not correct this.  The only way to edit those files again is to close LV completely and then reopen it.
      This is getting a bit tiring and I am just starting to develop this project.  I am working with LV2012f3 but have not yet tested this in the 2013 beta.  (I really do not want to port the whole project over at this time).
      Any thoughts?  Anyone else seen this?  I checked the known issues link and did not see anything related.
    • By gb119
      I have this memory that there was some way (like an ini key) to get the palette editor to save editted palettes 'in place' in the main installation directory and not into the user's LabVIEW Data folder.
      Does anyone know how to do that...?
    • By bbean
      Here is an interesting talk by Bret Victor. He has designed experimental UI concepts for Apple and others. To me its interesting to see how text based languages could catch up to LabVIEW's graphical style and even exceed it with instant visual feedback. Its also interesting to see how the IDE in any language could be improved.

      The video goes much deeper than programming languages and delves into life principals. Well worth the watch.
    • By Ton Plomp
      On Stackoverflow someone posted a question on how to recover a VI's password
      To my surprise there was a thorough answer containing two methods:
      Look up the stored MD5 hash in a VI file
      I can understand this, and am not really concerned, this might be a valid method if you know a password is from a given list (choosing a password from a dictionary is dumb anyway).
      Modify the LabVIEW executable binary to ignore the password checking.
      I have not tried this on LabVIEW 2011, but if this works it basically means that passwords are just a sign that says 'Do not trespass'

      Can anyone verify the LabVIEW edit function in 2011.
      On a more general discussion, does this troubles you anyway?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.