Code Inspection freezes when using the disable this Inspection feature

[CharlesRHall]

the ducks start spinning and it never returns - can close and reopne, but the ducks are still spinning - must close excel - arghhh

[retailcoder]

Must be a bug with the busy state of the inspection results viewmodel - triggering a reparse from the RD commandbar or main menu should bring it back to normal, after a successful parse and inspection run.

[retailcoder]

My guess is that the parser state says "I'm already all up-to-date" and never fires a "state changed" event with the "ready" state the viewmodel is expecting; if that's the case then modifying the content of a single module (a single character suffices) and reparsing, would fix the state glitch.

[comintern]

Replicated locally. This appears to be due to the command not running on the UI thread.

Exception thrown: 'System.ArgumentException' in Rubberduck.VBEditor.dll
2018-12-13 17:53:39.0483;ERROR;Rubberduck.UI.Command.ReparseCommand;System.ArgumentException: Expected COM object, but validation failed.
   at Rubberduck.VBEditor.ComManagement.TypeLibs.TypeLibWrapper..ctor(IntPtr rawObjectPtr, Boolean isRefCountedInput) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibs.cs:line 196
   at Rubberduck.VBEditor.ComManagement.TypeLibs.TypeLibWrapper.FromVBProject(IVBProject vbProject) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibs.cs:line 176
   at Rubberduck.VBEditor.ComManagement.TypeLibsAPI.VBETypeLibsAPI.CompileProject(IVBProject project) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibsAPI.cs:line 124
   at Rubberduck.UI.Command.ReparseCommand.AreAllProjectsCompiled(List`1& failedNames) in C:\Rubberduck\Rubberduck.Core\UI\Command\ReparseCommand.cs:line 91
   at Rubberduck.UI.Command.ReparseCommand.OnExecute(Object parameter) in C:\Rubberduck\Rubberduck.Core\UI\Command\ReparseCommand.cs:line 56
   at Rubberduck.UI.Command.CommandBase.Execute(Object parameter) in C:\Rubberduck\Rubberduck.Core\UI\Command\CommandBase.cs:line 47;System.ArgumentException: Expected COM object, but validation failed.
   at Rubberduck.VBEditor.ComManagement.TypeLibs.TypeLibWrapper..ctor(IntPtr rawObjectPtr, Boolean isRefCountedInput) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibs.cs:line 196
   at Rubberduck.VBEditor.ComManagement.TypeLibs.TypeLibWrapper.FromVBProject(IVBProject vbProject) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibs.cs:line 176
   at Rubberduck.VBEditor.ComManagement.TypeLibsAPI.VBETypeLibsAPI.CompileProject(IVBProject project) in C:\Rubberduck\Rubberduck.VBEEditor\ComManagement\TypeLibs\TypeLibsAPI.cs:line 124
   at Rubberduck.UI.Command.ReparseCommand.AreAllProjectsCompiled(List`1& failedNames) in C:\Rubberduck\Rubberduck.Core\UI\Command\ReparseCommand.cs:line 91
   at Rubberduck.UI.Command.ReparseCommand.OnExecute(Object parameter) in C:\Rubberduck\Rubberduck.Core\UI\Command\ReparseCommand.cs:line 56
   at Rubberduck.UI.Command.CommandBase.Execute(Object parameter) in C:\Rubberduck\Rubberduck.Core\UI\Command\CommandBase.cs:line 47

[retailcoder]

Hmm.. Ignore what I said then - this is another thing entirely. That said there is a busy state glitch when a reparse is requested from the inspection results toolwindow, and then cancelled ...but for that the code must be uncompilable and the parser setting for 'compile before parse' must be enabled.

[MDoerner]

The exception from the log above essentially has the same effect as canceling at that specific point.

BTW, we fire a state change to Ready on every successful parse, no matter whether there were changes or not.

[MDoerner]

The offending line is

Rubberduck/Rubberduck.Core/UI/Inspections/InspectionResultsViewModel.cs

Line 536 in 7e17257

Task.Run(() => _configService.SaveConfiguration(config)).ContinueWith(t => RefreshCommand.Execute(null));

.