Does not look like an open dialogue issue - as Kassu62 describes, everything but the operation of mouse actions within the drawing are works - e.g. you can save the file but you cannot place a component or move a wire.
Of course it could be that there is some kind of pop up dialog window that for some reason is not showing but I doubt it since this happens after very simple and common actions (e.g - edit a component - I can edit 5 components one after the other, 4 work ok and it happens on the 5th).
Maybe (very odd thing if it happens) the pop up dialog window is for some reason not closing properly - disappears from the screen but not actually closed and the system thinks it is still in the pop u window mode.
There was a freeze with similar symptoms in the nightly for a while after executing exchange footprint. (It was fixed weeks ago.) The “remedy” then was to select another layer and select back to the current one to unfreeze. However I believe this was specific to the nightly as I never noticed it in 4.07. Sometimes when I have tested the nightly in a very slow VM I have noticed a partial disconnect between cross-hair and mouse cursor, cross-hair having a serious delay.
This sounds a lot like the problem I am running into.
Here is a screen capture of:
- Changing a label - note how the cross-hairs track the cursor
- After the change the cross-hairs don’t track the cursor anymore.
- After opening and dismissing the Help window the cross-hairs track the cursor again.
I see them problem with both the 32- and 64-bit versions of 4.0.7. This is running under Win10 Pro on a Dell E7440 laptop.
Hello,
I confirm that this problem happened after my Windows 10 upgraded to the new 1709 revision (so called “Fall Creators Update”). The problem is exactly as described. I currently did not find any fix for that problem except switch to another window and come back to KiCAD which makes it practically reasonably unusable.
G13.
Has anybody already notified the developers over at the bugtracker?
Maybe they can nail down what the underlying problem is and guide users to a solution even if kicad version 4 will no longer get any update.
The error seems to be very rare, except for those unlucky users who has it all the time. So I don’t see what bugtracker notice would help. It seems, that KiCad do not have inbuilt trace system? The error report would be much better with error trace attachment. Like I said before, the error is very easy to reproduce, but that does not help developers to catch the error.
Well if every user who has it very time would report it maybe there is a pattern to be found. If none report it and no developer is lucky enough to have the one system setup that reliably leads to this bug then it will never be fixed.
1 Like
This is why the developers need users to spot these odd errors and report them. They will help you get the clues to find the bug.
I am a new user, but noticed the cursor hang on windows 10 as well. I just double click the windows Task View icon and it unfreezes for me. I have the creator update for windows as well.
Floyd
I’m just trying to compile KiCAD, but it’s a big mess with all dependencies of the project.
I’ll post a feedback here if I ever succeed in compiling!
Gorgo Treize.
I just heard about similar problem in Solid Works. My co-worker said, that after the Windows feature update the mouse cursor will stuck just like in KiCad. He has two monitors and his solution is to move mouse cursor to another monitor and back.
I have the same problem. The crosshair hangs after I for example have changed the value of a component. I use Windows 10 with all updates. When I activate another window and close it again, the crosshair follows the mouse cursor.
It is extremely annoying, please repair and issue a new version of KiCAD.
Regards,
Jorgen
This is a link. To read the full post click on it 
(Clicking somewhere on the top right edge of the gray area does also show the full post in some browsers)
To explain the “fix committed” state of that bug report:
As there will not be a further 4.0.x release, this will not be fixed within the KiCad 4 release series. The next release will be KiCad 5.x. (Will be released in a few months.)
The reason this is marked as fixed is that the nightly build (which will become KiCad 5) does not seem to experience this bug.
If somebody can replicate the bug in a recent nightly then it should either be reopened or a new bug for nightly builds should be created.
Dear eelik,
Yes, it is the same problem.
I have read the inputs to the forum and I got the impression that you wanted to see how many users have experienced the problem. All I wanted to flag is that I am experiencing the same problem.
When do you plan to release a new version?
Is a nightly build complete with libraries and everything like a complete release?
Regards,
Jorgen Sandberg
Did you even read my comment?
I gave you all the information that would answer your question.
(One part of the information is that we are only fellow users. I pointed you to the FAQ entry detailing what you should do if you found a bug. I also explained why this bug is already considered fixed in my last response.)
Dear Rene,
Yes, I have read your reply. However, I read and reacted to the mail from eelik, before I opened the mail from you.
Now, I know there will be a KiCAD version 5 in a couple of months and that the nightly build does not have the issue with a hanging crosshair. That is promising.
I used to use the hobby version of EAGLE. I paid about € 75 every two to three years when they came out with a major upgrade. Unfortunately, EAGLE does not offer a hobby license anymore. Someone recommended me to try KiCAD and I am in the learning phase. Most likely, I will leave it until the version 5 is released. I have tried a nightly build, but the libraries are not included, and I do not want to go through the hassle of finding out where to download them from and how to install them. I am not doing that kind of stuff regularly, so it is a major task for me to figure out exactly how to.
I realize, you and others are spending your spare time on KiCAD and make it available free to people like me. Thank you, that is very nice of you.
Regards,
Jorgen
Well the libs can be downloaded directly from the kicad webside.
KiCad seems to have had this bug for a surprisingly long time - and I don’t know why people are talking about NVidia drivers, because it’s clearly a straightforward KiCad UI bug. From the symptoms I can see that the EEschema window stops receiving mouse messages (e.g. loses mouse capture and doesn’t notice), and therefore the internal mouse position no longer tracks the system mouse cursor. When you click somewhere it’s the un-updated position that is assumed by the tool, and that’s probably not a meaningful position so you get the error beep.
If it was an NVidia or Windows bug then it wouldn’t only affect one window class in one application.