@Mat'sMug did you implement the code that determines that ThisWorkbook is a Workbook using the approach of hashing the VBIDE properties for the component and comparing to COM references?
Mary Meeker trend report for 2016 is out now. Interesting read to heard what's is developing and changed over the years. I used the slideshare version interesting how the generations is now encapsulated from slide 51 and 52. slideshare.net/kleinerperkins/…
And lastly the messaging evolution on slide 101. :)
Still lots of code checked in with low checkin of any changes to testing. 3 new classes added, and no RubberDuckModule code changes. I think the intention of Injection has been lost? Certainly when I try and find a place to inject at, I get terribly lost trying to understand where to do it.
> Are you using 1.4 or the latest commit? If the latest there is a debug option in VS that can help point point where the code fails which is helping developers here
> @PeterMTaylor Latest commit on next And well i could add a screenshot of the locals. The Callstack only shows [external Code] 
The last few Immediate Logs:
``` 2016-06-06 08:01:19.3457;WARN;Rubberduck.Parsing.Symbols.TypeAnnotationPass;Failed to resolve type VBE; Exception thrown: 'System.NotSupportedException' in Rubberduck.dll Exception thrown: 'System.NotSupportedExc
@Mat'sMug I've added debug output to VBA test-setups and teardowns, and to the test methods. I get debug output as expected and I get results in Rubberduck Test Explorer.
I suspect you have Macros disabled. The default, IIRC, is to allow digitall signed macros, but disable all other macros without prompting.
I think you need to switch to notifications for all macros
If I revert that setting to "Notifications for digitally signed macros, all other macros disabled", (and restart Outlook) then Rubberduck shows all tests as having passed (which it obviously incorrect), but I don't think the problem is with Outlook. It appears to be an over-optimistic AssertClass that defaults method outcomes to passed?
> Using the Test Explorer commands in Excel 2016 32-bit, I added a test module, and a single test method, to an empty Excel 2016 project. And then, again using the Test explorer menu commands, added another test module and single test method. I then edited the name of the 2nd test module's test method name to TestMethod2 for clarity (although with scoping, I shouldn't need to). So, I have:
TestModule1.TestMethod1 TestModule2.TestMethod2
All other module/test initialization/Cleanup methods
> Well, I decided that me *Ending* the code when it was breaking wasn't helping, because it was destroying the Assert objects unnecessarily, so I commented out the line: ```vb Assert.Fail "Test raised an error: #" & Err.Number & " - " & Err.Description ``` And then I get this output (indentation added for clarity): ```text ModuleInitialize (TestModule2) TestInitialize (TestModule2) TestMethod2 (TestModule2) TestCleanup (TestModule2) TestInitialize (TestModule2) TestMetho
Given this code: ``` Declare Function CreateProcess Lib "kernel32" _ Alias "CreateProcessA" (ByVal lpApplicationName As String, _ ByVal lpCommandLine As String, _ lpProcessAttributes As SECURITY_ATTRIBUTES, _ lpThreadAttributes As SECURITY_ATTRIBUTES, _
Given this code ``` Public Property Get Myrange() As Excel.Range Set Myrange = Range("myname")
End Property ```
 The return value is assigned actually as seen in the code.
@Gareth RubberduckModule isn't supposed to be modified much; by mere convention if a type implements an interface, that interface is automatically bound to the type that implements it, e.g. IFoo binds to Foo - unless you're getting an ActivationException and except for a few little things, there's normally little need to modify RubberduckModule.
> This isn't the same issue as #1703. The hooks shouldn't be waiting for Dispose to detach themselves - it probably should simply be handled in the WindowProc when a WM_DESTROY is received.
yeah. let's just exclude those from the inspection for now
@Hosch250 once you got that down, let's get serious with release notes - make sure you spare an hour for me tonight, I'd like to not be at work when the release build happens :)
Chat is behaving strangely on me some times. I get pings that I don't understand why I get, and I can't find exactly which message triggered the ping or why.
Anyway, while I'm here, is there any tool to help with the translation? @Vogel612 had something, didn't he?
A tool to see the strings in all languages at the same time would be nice
yup, and I used it for the French resources last week, works well. I filed a number of issues and he issued a new release
it took a little over 2 hours to go through everything... although I think I might have missed a few ones, things look funny on my fr-CA laptop at work
> Discovered this when I was doing some testing on how COM objects get released in the GC, and confirmed while testing a putative fix for #1710. This is very likely the cause of some of the weird shutdown errors, i.e. #1710, #1633, #1533, and #1438 (might be more, that's just a quick scan). These appear to be reporting "random" exceptions when closing because the exception that gets thrown would depend on the what the background thread is doing when tries to access something that the main thre
Yep. When the COM objects are GC'd in the main thread the finalizers are getting called on the RCWs. That lets the host destroy the objects because the reference counts all zero'd out. I'm not exactly sure why the runtime lets them do that, but it might have something to do with .NET's STA COM threading not complying 100% to the COM spec.
@Hosch250 probably knows more about the threading code than I do. There's code in the Dispose method of StaTaskScheduler to join all of the parser threads, but I'm not sure how to access it from App.
> @retailcoder wait what ? isn't cancel evaluated after the event and is used to cancel the save ? so it has to be byref right ? you're totaly confusing me now ...
how about we hard-code ThisWorkbook : Workbook and prohibit renaming ThisWorkbook? Any document module in Excel that's not named ThisWorkbook has to be a Worksheet then..
> The parens are mandatory in a *function* call; in a *procedure* call they basically force VBA to *evaluate* the parens-enclosed argument as a *value*, and pass it as such, effectively overriding the `ByRef` specifier.
So assuming a `Sub DoSomething(ByRef foo)` signature, `DoSomething (bar)` is force-passed by value.
In the case of a function, the same holds true - assuming `Function SomeFunction(ByRef foo)`, then `If SomeFunction((bar))` is force-passing `bar` by value, again overriding
@Comintern that was @ThunderFrame's original idea; I hadn't gone there because I was hoping to find a way to get the actual type name from somewhere reliable, that wouldn't require host-specific code
I'm working with the VBIDE API, and can't assume that the host application is Excel, or any Office app either.
So all I know is that I'm looking at a VBComponent, and that its Type is vbext_ct_document.
In the VBE's immediate pane I can get this output:
?TypeName(Application.VBE.ActiveVBProjec...
> i never understood the concept of omitting the parenthesis because `Call MySub(arg , arg2) ` looks a lot nicer to me then `Mysub arg, arg2` And now you're saying me that they do behave so drastically different ? This is just another creepy thing about vba :D
Funny side note: I've been doing the parenthesis thing everytime with the `cancel` thing and i never noticed this behavior.
> @transistor1 did they fix the *force focus* bug? The VBIDE API doesn't always correctly set the focus where we tell it to, and per #617 using NetOffice would break the (quite important) hack we're using to force-focus a given selection.
Also, to be honest I'm not too eager to switch to NetOffice anyway, especially since we don't *only* have Office PIA's referenced - having different abstraction levels for what amounts to the same concern (interacting with the host app and the VBE), doesn't
This is probably generally applicable to all documents:
?TypeName(Application.VBE.ActiveVBProject.VBComponents("Sheet1").Properties("Saved").Object)
[Doesn't support this property or method]
?TypeName(Application.VBE.ActiveVBProject.VBComponents("ThisWorkbook").Properties("Saved").Object)
Nothing
> This was the concept i was used to ... `call DoSomething(bar)`= byref `DoSomething bar` = byref `call DoSomething((bar))`= byval <-- only this should force byval
> This code should resolve to an event. It resolves to a procedure because it is stuck into `ThisWorkbook` instead of `Workbook`. The same problem exists for `Sheet1` and `Worksheet` and `Class1` and `Class` and `UserForm1` and `UserForm` events. Standard modules do not have built-in events, so they don't have this problem. ``` Option Explicit
Private Sub Workbook_BeforeSave(ByVal SaveAsUI As Boolean, ByRef cancel As Boolean)
handler (cancel) If cancel Then MsgBox "Save canceled
I don't think I came across a description of this bug directly, except that I saw a reference to it [here](https://github.com/rubberduck-vba/Rubberduck/pull/617#issuecomment-111698129), but I can certainly look at it if you point me to the Rubberduck code that handles it
FWIW, Each NetOffice object has an `UnderlyingObject` property, which points directly to the COM object if it is needed, so I'm sure the hack mentioned by @ckuhn203 could probably be
I'm working with the VBIDE API, and can't assume that the host application is Excel, or any Office app either.
So all I know is that I'm looking at a VBComponent, and that its Type is vbext_ct_document.
In the VBE's immediate pane I can get this output:
?TypeName(Application.VBE.ActiveVBProjec...
VBA Rubberducking
VBA Rubberducking