> I was actually just looking at that code. We have some bad abstractions going on. Our "menus" are often really a single button and a whole "app" connected to it. DockablePresenter implementations feel more like the views they control than they should. Life might be easier if we find a way to keep a handle on the actual ToolWindows.
> A number of bugs have recently been reported that seem to only affect Office 2013. We could really use a hand detecting and fixing bugs in that environment.
> I just had a similar crash with Excel 2007. Not exactly the same exception, but it crashed at the same point -- after closing VBA editor and then Excel. This one only happens if you close it while the Code Editor is still parsing. ************** Exception Text ************** System.Runtime.InteropServices.COMException (0x80070006): System Error &H80070006 (-2147024890). The handle is invalid. at Microsoft.Vbe.Interop._VBComponent.get_Name() at...
Rubberduck.UI.CodeExplorer.CodeExplorerDockablePresenter.<AddModuleNodesAsync>d__15.MoveNext() in c:\Users\Christopher\Source\Repos\Rubberduck\RetailCoder.VBE\UI\CodeExplorer\CodeExplorerDockablePresenter.cs:line 122 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at...
Rubberduck.UI.CodeExplorer.CodeExplorerDockablePresenter.<>c__DisplayClassd.<<AddProjectNodes>b__c>d__f.MoveNext() in c:\Users\Christopher\Source\Repos\Rubberduck\RetailCoder.VBE\UI\CodeExplorer\CodeExplorerDockablePresenter.cs:line 97 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__4(Object state) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32...
> That one makes sense. We can handle that I believe. It crashes because the VBProjects/Components are no longer available, but the parser is still trying to parse. Related yet separate issue.
It's not a NRE, but you're right it's probably better handled elsewhere; we need a way to abort creating tree nodes when the module gets closed while the TreeViewListener is creating nodes.
Right. So we get 1.21 out and then address all that in 1.22 or 1.3?
Like, master is on a feature-freeze until next release right?
And 1.21 branch should be closed now
I need to read those x64 links you gave me. Then when I get the x64 installer up I'll have to take screenshots for the release notes, the website's features page and the wiki
That's... Weird. The post build should be registering the keys (except the Addins64).
So, you're using "AnyCPU", Extracting Com Info and checked COM Interop for the dll, extracting but unchecked for the tlb... Extension is registered under add-ins64. Right?
@rubberduckvba “@CommitStrip: Finishing a project is as easy as closing the very last ticket http://www.commitstrip.com/2014/12/02/to-a-project-finished-at-last/ http://t.co/NlmsqHCAlr”
> 3>ISEXP : warning : -4354: The build was unable to extract COM information from the file C:\Users\Mathieu\Source\Repos\Rubberduck\RetailCoder.VBE\bin\Release64\Rubberduck.dll in component Rubberduck.Primary_output1. Please ensure that the file is self-registering and verify that the self-registration process does not fail.
Custom actions and Self Registration is NOT a best practice.
If your version of InstallShield doesn't support COM Interop, run the command:
regasm foo.dll /regfile:foo.reg
Now import that reg file into InstallShield and tweak things file foo.dll to [INSTALLDIR]foo.dll.
If your version of Ins...
Custom actions and Self Registration is NOT a best practice.
If your version of InstallShield doesn't support COM Interop, run the command:
regasm foo.dll /regfile:foo.reg
Now import that reg file into InstallShield and tweak things file foo.dll to [INSTALLDIR]foo.dll.
If your version of Ins...
VBA Rubberducking
VBA Rubberducking