« first day (1499 days earlier)      last day (1681 days later) » 

12:00 AM
RELOAD!
[rubberduck-vba/Rubberduck] 2 commits. 2 closed issues. 3 issue comments. 64 additions. 8 deletions.
> This should be a fairly easy fix. Do we know of any other keywords that are valid with a colon after them?
 
 
2 hours later…
2:28 AM
> A couple things to note here before I forget them. The ole32 library has functions that should make a lot of this trivial, i.e. `ProgIDFromCLSID`, `CLSIDFromProgID`, etc.

The question of whether or not an object can be created by newing it up *should* be just checking for the associated CoClass to see if it is creatable.

AFICT from casual inspection of the vbe7.dll imports, `CreateObject` likely boils down to getting a CLSID from the class parameter (probably just `CLSIDFromProgID`), the
 
@Duga The corollary to that is that RD could easily use the same ole32.dll functions to implement an early-binding to late-binding refactor and visa-versa.
 
Just watched The Fellowship of the Ring with my boys
 
The new version?
 
There's a new version?
@Comintern oooh
 
Newer I should say. Wasn't there an animated one in the 70s or 80s?
The Lord of the Rings is a 1978 American-British-Spanish animated high fantasy film directed by Ralph Bakshi. It is an adaptation of J. R. R. Tolkien's high fantasy epic The Lord of the Rings, comprising The Fellowship of the Ring and the first half of The Two Towers. Set in Middle-earth, the film follows a group of hobbits, elves, men, dwarves, and wizards who form a fellowship. They embark on a quest to destroy the One Ring made by the Dark Lord Sauron, and ensure his destruction. Ralph Bakshi encountered Tolkien's writing early in his career, and had made several attempts to produce The Lord...
 
2:36 AM
No no the Peter Jackson movie
had to cheer one up over Boromir's demise
 
I should sit down and watch all of those again. Epic.
 
Oh got an email, the podcast I recorded Monday is live
 
I really wish I knew French.
Or Spanish for that matter.
Maybe I'll have my daughter translate. :-)
She's much more of a linguist than I am.
 
Ugh. 4% battery. I'll listen and put up an English transcript on RD News ASAP
 
3:34 AM
Unrelated but thought to share there’s an OpenAPI being sponsored github.com/OAI/OpenAPI-Specification to find a way to discover and provide info about technical info simply that Microsoft supports also as their chair on the board.
 
 
2 hours later…
5:25 AM
Mathieu Guindon en entrevue au Visual Studio Talk Show avec #MTLMVP Mario Cardinal et @GuyBarrette: http://visualstudiotalkshow.libsyn.com/0221-mathieu-guindon-rubberduck-vba #VBA
 
So close...
12>EXEC : warning : Error occurred with using VSSetup module
12>  \\VBOXSVR\comintern\Rubberduck\Rubberduck.Deployment\BuildRegistryScript.ps1 : Could not load file or assembly
12>  'file:///C:\Program Files\WindowsPowerShell\Modules\VSSetup\Microsoft.VisualStudio.Setup.PowerShell.dll' or one of its
12>  dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
12>  At line:1 char:1
12>  + \\VBOXSVR\comintern\Rubberduck\Rubberduck.Deployment\BuildRegistryScr ...
12>  + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Any ideas on what components I'm missing this time around?
 
5:52 AM
Apparently none. Stupid Windows 10 blocked files...
 
 
3 hours later…
8:45 AM
That error sounds familiar.
@Comintern Did you set your powerscript execution policy? The default one is too strict to build the deployment project.
 
8:57 AM
Hm, according to the wiki it should work without the policy change now, but you could give it a try.
 
 
3 hours later…
12:05 PM
@Comintern was it a file in particular? Probably should update the wiki to add that step of unblocking.
 
12:38 PM
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report
> Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/ab68630a4e357e8b7b11eae029839774016287e3?src=pr&el=desc) will **decrease** coverage by `<.01%`.
> The diff coverage is `54.26%`.


```diff
@@ Coverage Diff @@
## next #3956 +/- ##
=======================
> Note: when resolving the conflicts for this PR, I noticed there were some references (System.Web in particular) that shouldn't be present in the Rubberduck.Core and Rubberduck.Main; so I removed them.
[rubberduck-vba/Rubberduck] build for commit 8f5ff7c2 on unknown branch: AppVeyor build failed
BUILD FAILURE!
 
oh come on
 
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report
> Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/ab68630a4e357e8b7b11eae029839774016287e3?src=pr&el=desc) will **decrease** coverage by `<.01%`.
> The diff coverage is `54.26%`.


```diff
@@ Coverage Diff @@
## next #3956 +/- ##
=======================
 
12:53 PM
grumble now i have a build that I can either build locally exclusively or builds on AV exclusively. All because I put in the debug version of Windsor for my another PR....
 
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report
> Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/ab68630a4e357e8b7b11eae029839774016287e3?src=pr&el=desc) will **decrease** coverage by `0.14%`.
> The diff coverage is `28.19%`.


```diff
@@ Coverage Diff @@
## next #3956 +/- ##
=======================
[rubberduck-vba/Rubberduck] build for commit 7ab12298 on unknown branch: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit 7ab12298 on unknown branch: 52.32% (target 0%)
 
1:13 PM
@Duga I wonder if it's just making the numbers up. The commit had no substantial changes besides resolving conflicts and references. Going from +0.02% from prior report to -0.14% seems a bit too much
 
 
1 hour later…
2:15 PM
Um so, I've never come back from the dead before, but did I miss anything or was it really "Hi, a lot has changed in the code since I was last here"?
Welcome back Comintern :)
 
2:49 PM
@M.Doerner I got the execution policy set up before I hit that error, but when I re-installed Visual Studio I only ended up with 4 modules. I had to install the VSSetup module manually, but it looks like it might be missing a dependency.
@puzzlepiece87 Thanks. I believe it was "FML. I have some catching up to do."
 
TIL - You can create a function called Property but you can't use it on LHS without using Call, otherwise you get Compile Error: Expected Get or Let or Set
 
lol
TIL - Either VS or NUnit doesn't like running unit tests from a network share. Moving the project to a local drive solves all of the bizarre test discovery problems. Obnoxious.
On the other hand, I'm now completely up and running.
 
3:19 PM
and, in addition to the private fields of a class being visible in the Locals Window, and queryable from the Immediate Window, you can also execute private procedures, and query private functions from the Immediate Window, assuming you know the name and arguments.
 
Seriously, WTF Microsoft? Adding my network share as a trusted location triggers execution security warnings, but removing it doesn't? I feel sooooo secure now... o_O
 
3:42 PM
@Comintern That's true xD
 
Now I need to figure out why I have 201 failing tests when the only change I made wasn't covered by unit tests. Hmmm....
I'm assuming that next is passing?
 
yeap. can't merge otherwise
 
Did you break the parser? That would result in about 200 failing tests.
 
Maybe. The only thing I touched was VBENativeServices though. I'm suspecting that something got pulled in with Linux line endings.
[7/14/2018 10:27:50 AM Warning] line 4:9 extraneous input 'SomeIdentifier' expecting {'=', WS, LINE_CONTINUATION}
[7/14/2018 10:27:50 AM Warning] line 4:9 extraneous input 'SomeIdentifier' expecting {'=', WS, LINE_CONTINUATION}
[7/14/2018 10:28:17 AM Warning] line 5:18 mismatched input '\n' expecting {'=', WS, LINE_CONTINUATION}
[7/14/2018 10:28:17 AM Warning] line 5:18 mismatched input '\n' expecting {'=', WS, LINE_CONTINUATION}
[7/14/2018 10:28:17 AM Warning] line 17:16 mismatched input '\n' expecting {'=', WS, LINE_CONTINUATION}
 
4:01 PM
Re Leaky private fields in the debugger - So, I thought I'd take advantage of the VBE's inability to resolve Interfaces in the debugger. If my private field this is declared as an interface, then the fields and properties of this are unviewable in the Locals Window and unreachable in the Immediate Window. So, private variables are "safe" again, but I have to create an interface and a class to buy that security.
takes off hacker hat
 
Yep. It was line endings. Problem solved.
Looks like I need either a lazy hWnd <-> Window association mechanism or "TODO: Find a better method to match code panes to windows than testing the captions."
 
4:18 PM
@Malachi There was one small item in there that I hadn't known. Didn't realize how much I knew. Thought everyone knew that stuff.
 
Dunning-Kruger in action
 
@IvenBach Imposter Syndrome much?
@this - I think the Interface approach (above), to hiding fields is a reasonable solution. I can't think of a way to retrieve any Private or Concrete member, other than somebody inspecting the property in Excel's memory, and that takes a great deal of skill, as the ,VBE can't seem to do it, and RD doesn't know how either. OK, so maybe @WaynePhillipsEA could work it out.
 
5:08 PM
@ThunderFrame Did I get understand correctly that my private variables are safe baceuse, even in VBA, I only code against interfaces.
 
@ThunderFrame Am I remembering correctly that the VBA IWindow interface doesn't return a reliable hWnd?
 
@Comintern IIRC, most windows have an hWnd of 0.
@M.Doerner yes, should be fine. I was referring to the conversation a couple of days ago, about Locals and Immediate windows giving up the values of private variables and fields, and exposing the private methods of a concrete class.
 
Yeah, that's what I thought. Need to find a work-around for RD picking up IWindows before they've set their caption.
 
We had come to the conclusion that private variables weren't reliably private, but coding through an interface leaves all private variables hidden and inaccessible.
@Comintern I also suspect that the codepane hWnd/window changes as it opens, but don't have proof yet.
 
Hey @M.Doerner you around?
I could use a hand for writing unit tests to the Property-Injection component I built
 
5:17 PM
Sorry, I won't be around the next few hours.
 
sure, no prob
I'll continue to move stuff around then :)
 
5:30 PM
@ThunderFrame That might explain some of the behavior I'm seeing. Eventually I might need to attach an event handler to the MDIClient in addition to the main window. Think I have a cheap and easy work-around until then.
 
@Comintern My suspicions grew when opening a module in one of the Unviewable+ sample workbooks, where the real modules weren't visible in Project Explorer, but 3 dummy module names with special characters did appear in Project Explorer (as copyright notices), but without a corresponding module stream in the project binary. If you tried to open the module, a blank window would begin to open and then freeze, rendering your IDE somewhat unusable.
I think MDIChildHack might be the window that appears and gets stuck, and then, had the real stream been found, a new window would replace MDIChildHack to display the module.
but I can't know for certain, because by the time the window freezes, it's too late to Spy++ anything
 
Well, that was crashtastic. It apparenty recycles the entire CodePane, not just the window.
 
> Given these declarations in **Class1**:
```vb
Public a As String
Public b As Collection

Public Property Get c() As String
End Property

Public Property Let c(RHS As String)
End Property
```

Invoking _Implement Interface_ in **Class2** results in:
```vb
Implements Class1

Private Property Get Class1_c() As String
Err.Raise 5 'TODO implement interface member
End Property

Private Property Let Class1_c(ByRef RHS As String)
Err.Raise 5 'TODO implement interface membe
 
5:46 PM
Hmmm, why would `CodePane.IsWrappingNullReference` return false and yet:
System.Runtime.InteropServices.InvalidComObjectException: 'COM object that has been separated from its underlying RCW cannot be used.'
 
5:59 PM
> Given these declarations in _Class1_:
```vb
Public Property Get a() As String
End Property
Public Property Let a(RHS As String)
End Property
Public Property Get b() As String
End Property
Public Property Let b(RHS As String)
End Property
```

And a partially implemented `Class2`, where the getter for `Class1_a` and the getter and letter for `Class1_b` are not present:
```vb
Implements Class1

Private Property Let Class1_b(RHS As String)
End Property
```

Executing the _Impl
 
6:13 PM
> As an aside, can anyone explain why the VBE generates signatures for variables with ByVal, and signatures for properties with an implicit ByRef? And anyway, didn't we determine that property procedures always take their arguments ByVal regardless of whether there's an implicit or explic
 
6:42 PM
SafeComWrapper doesn't appear to be thread safe.
Either that or I'm somehow holding a reference to an object that another process disposed.
 
6:58 PM
@ThunderFrame dont you lose it all again once you cast the this field?
@Comintern just in case. Are you using provider to retrieve the components? Max introduced a provider to encapsulate the lifecycle management of projects and components.
 
@this my interface is Private, in an add-in, only the main class is PublicNotCreatable, so there's no way to cast.
 
@this No, but I should only have a reference that was created internally in VBENativeServices
This is the failing code:
        private void OnVbeSelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            if (e.CodePane == null || e.CodePane.IsWrappingNullReference || e.CodePane.HasBeenReleased)
            {
                return;
            }

            new Task(() =>
            {
                var eventArgs = new DeclarationChangedEventArgs(e.CodePane, _parser.State.FindSelectedDeclaration(e.CodePane));
                DispatchSelectedDeclaration(eventArgs);
            }).Start();
Note that I exposed HasBeenReleased as public while I'm debugging it.
e.CodePane is throwing System.Runtime.InteropServices.InvalidComObjectException "COM object that has been separated from its underlying RCW cannot be used" further down the call stack, but it's showing HasBeenReleased as being true in the immediate window.
Only way that happens is if somebody, somewhere called Dispose() on an object that they shouldn't have.
 
7:41 PM
Managed Debugging Assistant 'RaceOnRCWCleanup'
An attempt has been made to free an RCW that is in use.  The RCW is in use on the active thread or another thread.  Attempting to free an in-use RCW can cause corruption or data loss.
Yay! :-(
Getting closer at least. Apparently it's in Hotkeys.
Or... not. It's re-entry into VbeEventCallback.
 
8:26 PM
There are using in vbenativeservices that shouldnt be
Cannot use a using when sendig the argument via event
Need to dispose only when the handler is null
Better yet use the key and then retrieve via provider. That way there is no collission on who should clean up
 
Yeah, I've been mulling over turning it into a full fledged dispatcher.
 
Events really confuse the cleanup issue
 
^^
 
I think well be better off never directly sending a com pbject over event.
Learnt that the hard way, thanks to Max
 
Yeah, that would be the idea scenario. In this particular case, it might be sufficient to just send a Selection.
 
8:35 PM
Dont u need qualifiedselection
 
There are also issues with re-entry into the unmanaged event callback.
I'd initially spun the event processing into tasks to stop the UI from getting sluggish on huge projects, but it makes it damned near impossible to manage object lifespans.
The selection changed event is fired every time the cursor moves, so can get to be like typing on a 1980's terminal after a while.
I think I may have found the issue in the ReferencedDeclarationsCollector too.
Somehow null interfaces are being added to the KnownTypes cache. I need to investigate that further though.
For that one, I might push a partial quick-fix pending tracking down where it's coming from. Not loading libraries correctly is kind of a big deal.
 
> > Microsoft .NET Framework 4.5 installation was not detected.

On which Rubberduck version XP-compatibility support was ended?
.
 
@ThunderFrame ah I understand now. Yeah, that'd work, too. If you didn't want to do the investment of interface + class, there's the static field method that I showed the other day. #ChooseYourPoison
@Comintern in case you didn't see it already, @mansellan did make some change to handle the bizarre case of where VB6 type libs had no name or something like that.
@Duga a bit late to the party, eh? I don't even remember RD supporting XP? Ever?
 
8:51 PM
@this I think at some point it might have targeted an earlier framework. MS stopped supporting .NET frameworks for XP starting with 4.5.
 
Here's the PR I'm thinking of: github.com/rubberduck-vba/Rubberduck/pull/3991
yeah and when I started, we were already on 4.5.
 
It was targeting 4.5 as early as 5/9/2015 when the project was split into multiple dlls.
 
> I don't think we ever supported XP because Rubberduck has been on v4.5 in the v2.0 cycle and we are currently on 4.6.

See #277 -- that discussion was had in 2015 and decision already made since.
 
^^beat me to it.
 
Have to go - hope the PR link helps a bit. Good luck hunting down the lost COM sheeps!
 
9:16 PM
> We never have supported XP. Windows had ended support for XP around the same time, if not before, this project started.

I know a lot of people are still using XP, but I really encourage you to upgrade if you can. Continuing to use XP is a security risk.
 
9:40 PM
> I knew it already from somewhere, just recently one person convinced me that he installed it on XP. I tried it, and, of course, unsuccessfully due to Framework 4.5 :) So I thought that he was talking about one of the early releases...

Thank you for prompt replies.
.
 
9:51 PM
> Should I to change the original issue title, removing "EOL" from it, to not mislead people, because there was not XP-compatibility at all?
.
 
10:40 PM
> Nah. I think it’s all right.
 
10:53 PM
@Comintern I think no safe COM wrapper should ever be on an argument of an event. However, if it is, the event has to be handled synchronously because the create or the safe COM wrapper has to dispose it.
To ensure a proper state at shutdown, we have to dispose all COM wrappers we create.
 
@M.Doerner Yep, and there's the rub. When that code was originally written, the listener needed an IWindow interface.
I don't think the disposal is a problem, it's managing state. The re-entry through the unmanaged event handler makes that a PITA.
BTW, I tracked down the COM Collector issue.
PR coming up.
 
11:28 PM
> I don't have VB6 installed yet, so this is untested there. If anything this would fix things and not break them though.

For future reference, the problem is that when caching was added to more types it was under the assumption that everything would have a Guid. This **_should only be assumed to be true of interfaces and coclasses_** (required, I believe), and I'm not 100% sure about the coclasses.
 
11:41 PM
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4181?src=pr&el=h1) Report
> Merging [#4181](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4181?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/ab68630a4e357e8b7b11eae029839774016287e3?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `0%`.


```diff
@@ Coverage Diff @@
## next #4181 +/- ##
===========================
[rubberduck-vba/Rubberduck] build for commit 12718a19 on unknown branch: 52.46% (target 0%)
[rubberduck-vba/Rubberduck] build for commit 12718a19 on unknown branch: AppVeyor build succeeded
 

« first day (1499 days earlier)      last day (1681 days later) »