« first day (1622 days earlier)      last day (1558 days later) » 

12:00 AM
Speaking of which, I should fix #4476 - that might require a breaking change.
 
@Vogel612 AIUI, they expected 50K PRs but only got 40 completed. Maybe they gave the surplus to those who were close?
 
@Vogel612 The EasyHooks issue was that it was hard coded to use vbe7.dll. I think the fix already merged.
 
RELOAD!
 
@Comintern there also was something about it not being shipped properly.
 
[rubberduck-vba/Rubberduck] 6 commits. 6 closed issues. 8 issue comments. 376 additions. 418 deletions.
 
12:01 AM
double delegating, I think
I don't htink that still is fixed
 
No, that was #4476, which is still open. Was there a problem with the binaries in the installer?
 
Shouldn't be.
checking to make sure
 
the original NuGet package installed the EasyHook files to somewhere outside the project's .nucache
but that's not allowed any more with the new PackageReference way of referencing NuGet packages
 
Oct 31 at 12:16, by Duga
> Closes #4464 This fixes two issues: 1) Since csproj format change, EasyHook was apparently broken because certain files from the content folder wasn't being copied over to the output directory. This now does and thus enable use of stubs/fakes. 2) Originally, stubs/fakes had a hard-coded reference to vbe7 library. This wouldn't work for those rocking it old skool with VB6 or pre-2010 Office. This makes use of the existing IVBERuntime implementations, which has a VBERuntimeAccessor...
 
right I now remember.
 
12:03 AM
:+1:
Aight. I'm off to sleep. Gotta check in at my local administration in ~7-9 hours
 
going to verify that this is still good with the next
later!
 
I really want to avoid that 1k€ fine they could make me pay...
 
the thing is I probably should verify the fakes on the vb6, too...
 
meatbag testing! :)
 
this meatbag is confused.
(and has poor cropping skillz to boot)
Fakes doesn't seem to work in VB6
unit testing without fakes is ok, though.
 
12:35 AM
Wut?
@this Wrong dll.
> {"The given library is not loaded into the current process."}
 
12:55 AM
@this Later, sure.
 
 
1 hour later…
2:15 AM
My two msdocs pull requests were merged =)
 
2:30 AM
I just accepted my foods pull request. :wink:
 
I’m using community myself @commintern and I think I could help out why his configuration
Is playing up but will need to see my PC at home and wait for my slow hard disk to catch up on any updates.
 
@Comintern I was afraid of that.
I will double check but I think it's because VB6 rusn with msvmvb6.dll (however it's spelt) instead of vb6.dll
But doesn't explain the other one about msgbox not having the passthrough -- that was on excel.
 
@this When I check process explorer, it had vba6.dll loaded.
 
oh.
dammit, why can't theory and practice play nicely once in while?!?
 
IKR?
 
2:35 AM
hmm. which vba6, though?
 
@this Cause this is real life?
 
I'm real life? How so convenient....
 
Life never lets things go as planned.
 
Ahah.
You can't use the setter at all - it doesn't care what the value is:
public override bool PassThrough
{
    get { return false; }
    // ReSharper disable once ValueParameterNotUsed
    set
    {
        Verifier.SuppressAsserts();
        AssertHandler.OnAssertInconclusive(string.Format(AssertMessages.Assert_InvalidFakePassThrough, "MsgBox"));
    }
}
 
uh....
 
2:40 AM
Probably poor UX there.
 
i'm wondering why did it work when I set it to True earlier for my other PR
 
Did it actually get called?
 
well, it had an effect
I can't remember if I debugged the C# side... I am thinking no.
but it did make a difference in whether I set hte property or not for that crashing due to double delegation issue
hmm. VB6's references shows VBA using msvmvb6.dll.
 
Not all of them suppress pass-through - Time and Date don't for example.
 
hmm. it might have been msgbox I got unlucky on
 
2:48 AM
There should probably be another base class that doesn't extend PassThrough at all.
 
yes that might be better
COM interfaces can be inherited, so splitting the PassThrough into a separate interface (which is a breaking change) is easy to do
 
I was probably avoiding having to come up with another stinking name.
 
nah, no need. Just a new interface that extends the fakes interface, moving that one member over.
 
I'm not horribly adverse to a breaking change in there - this has always been "experimental", and it's pretty low impact.
 
since the code wouldn't have worked, the breaking change should be ok.
^
 
2:50 AM
 
Any code that didn't call PassThrough shouldn't have been broken though. I need to get back in a much around in that namespace some more.
 
no, not that one
that one
 
lol
The alt text is great.
 
i'm missing something. PE sez:
---------------------------
Process Explorer Error
---------------------------
The owning process is VB6.EXE (process ID 28220), which is not currently visible in the process list.
---------------------------
OK
---------------------------
it's 32-bit PE
guess I can't see it when i'm running PE elevated.
Makes perfect sense.
 
2:55 AM
clear to merge the sunburst PR?
 
I'm good. @this?
 
I say go ahead
in my vb6, I don't hvae vbe6.dll loaded
that is going to complicate the loading logic....
 
Certainly not going to make anything more broken.
 
    set
    {
        SetValue(MaxNumberProperty, value);
        OnPropertyChanged(new DependencyPropertyChangedEventArgs(MaxNumberProperty, GetValue(MaxNumberProperty), value));
 
Need to think about it, though. vbe6.dll and msvmvb6.dll will be both "6.0" for the version
 
2:59 AM
GetValue gets the DP ref, which SetValue already reassigned; the handler sees the same old & new values
 
Yeah, that was kind of dumb, wasn't it.
 
so I have to actually know I'm in VB6 vs. VBA.
 
WTH did that work?
Ummm... are we sure that we got the easyhook binaries in the installer?
> {"Unable to load DLL 'EasyHook32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}
 
@Comintern are you running this from the installer?
 
3:05 AM
[rubberduck-vba/Rubberduck] bclothier project card. Enough said.
 
@this No, running from the debugger. Is it not getting copied in the debug build?
 
it should be
 
> In testing it seems that VB6 will not necessarily load `vbe6.dll`, but rather `msvmvb6.dll` which is very similar library.

The present logic switches based on the VBE's `Version` property. This is no longer sufficient to handle VB6 support. For that reason, fakes will not work in VB6. We need a way of detecting whether we are loaded inside a VB6 host vs VBA host and thus switch the DLL name accordingly.
 
in Rubberduck.Deployment.
 
3:07 AM
do you see it in your folder?
 
Nope. Only EasyHook.dll, which I'm presuming is the 64 bit version.
 
hmm.
that'd be a result of the reference
 
Or wait, is that the .NET assembly? I can't remember if there's an EasyHook64.dll or not.
 
but the other files have to be copied
and I think they are supposed to be as part of the csproj
yeah
<Content Include="..\packages\EasyHook.2.7.6684\content\net40\**" CopyToPublishDirectory="PreserveNewest" Link="%(Filename)%(Extension)" />
maybe the version or path isn't the same?
Pretty sure the one you saw is just the .net assembly.
 
What is that directory relative to?
 
3:14 AM
that's the csproj for Rubberduck.Deployment
so therefore, inside the Rubberduck.Deployment
the packages should be just at the Rubberduck's solution level
 
Huh. That might be @IvenBach's issue.
 
how so?
 
Those go into a couple Nuget caches.
 
it's literally the last thing to build.
well, not necessarily. test project can be built concurrently
but it's way after the core for sure
sooo.... packages isn't safe to use?
 
Hmmm... I only have copies of the binaries in my RD backup folder.
Not the current.
 
3:18 AM
hmm.
 
I've got a huge cache here: C:\Users\comintern\.nuget\packages
 
and we need those binaries for sure.
there's an open issue for copying contents to output, unfortunately
that's why we had this hack in the csproj
but obviously that won't work
 
My version is 2.7.6684 though.
 
therefore we need to hack another hack --- an EasyHook folder in the source control with the binaries we need. :\
that means we'll have to just remember to update that when we update the EasyHook. :(
 
We'd have to do that anyway - the version is hard coded.
I really dislike the idea of linked binaries in SC.
 
Can't you force it to load packages locally?
 
uh, i have no idea...
Remember, that's Vogel who mainly worked on the csproj conversion.
 
This is why package managers shouldn't cache. It's just stupid.
This isn't 1995 - I have plenty of drive space to fill with nugetty goodness.
 
[rubberduck-vba/Rubberduck] build for commit 20f8d3bd on unknown branch: AppVeyor build succeeded
 
I'm cleaning to see if this works
 
3:27 AM
[rubberduck-vba/Rubberduck] retailcoder is checking what fun stuff @Duga can say about project cards
 
uh. clean didn't actually delete files.
 
Wut?
 
MSBuild cleans like my kid.
3
 
3:28 AM
[rubberduck-vba/Rubberduck] retailcoder pushed 14 commits to next (only showing some of them below)
[rubberduck-vba/Rubberduck] IvenBach pushed commit ab357c3e to next: Merge branch 'next' of github.com/rubberduck-vba/Rubberduck into cominternNext
[rubberduck-vba/Rubberduck] comintern pushed commit 92090a3c to next: merge commit
[rubberduck-vba/Rubberduck] comintern pushed commit 15671d8d to next: Fix bindings.
[rubberduck-vba/Rubberduck] comintern pushed commit 479f27ec to next: Removed commented code.
[rubberduck-vba/Rubberduck] comintern pushed commit 3ce37919 to next: fix min and max properties
 
IKR?
 
[rubberduck-vba/Rubberduck] comintern pushed commit 184d32a6 to next: Add missing resource string.
[rubberduck-vba/Rubberduck] IvenBach pushed commit f77e8683 to next: Merge branch 'next' of github.com/comintern/Rubberduck into cominternNext
 
but i found why - excel was still open
 
[rubberduck-vba/Rubberduck] comintern pushed commit c0e451ee to next: Fix OnPropertyChanged arguments.
[rubberduck-vba/Rubberduck] comintern pushed commit 20f8d3bd to next: Merge branch 'next' of github.com/comintern/Rubberduck into next
Merge pull request #4501 from comintern/next

Switch to Sunburst SDK build
 
you'd think it'd say that clean failed because file was in use....
ok, so the Rubberduck.Deployment is now empty and I commented out the original copy logic. Let's see if htis new hack works.
 
3:30 AM
@this it's probably the Exception.InnerException.InnerException.InnerException.InnerException
 
@Duga really looks weird. I wonder if github is really doing this right.
@MathieuGuindon IKR?
 
We might want to bump EasyHook to the current version - there are a couple closed issues that we probably want to update for in the 64 bit dll.
 
That's why I don't relish the idea of binaries in sc
I want this nuget'd, dang it
 
> 2.7.6684.0:
1. x64 trampoline: ensure stack is 16 bytes aligned (#214 and #234)
I don't think we have any current issues with that, but that's kinda important...
 
uh, does it follow that a clean of project necessitates cleaning all dependent projects?
 
3:39 AM
@this Shouldn't
 
welp it did
@Comintern nice!
 
Huh. OCD clean.
 
what did you change?
 
I copied the dlls by hand into the output directory to make sure the fakes worked.
Just a build issue and a rename to vba6.dll
What version of Office used vbe6.dll?
 
2K
wait no
that can't be
 
3:41 AM
2007
vba 7 was introduced in 2010
hmm. yet I had the dll and I couldn't run....
 
Hmmm... Do we have anything that is already broken prior to 2010?
 
@Comintern the oldest or the newest?
 
Oldest.
I mean newest.
 
vb98 would have been Office97
 
Didn't we break compatibility with some early office versions already?
 
3:43 AM
I think so
 
IIRC we're good up to 2000
 
I'm trying to decide if I care about supporting vbe6.dll
@this Crap.
 
OTOH, running 2003 on Win10?
 
That means we probably need to use the host process to determine if it's running under VB6.
 
Remember that we need .NET 4.6... that's Windows Vista SP1 or newer
 
3:44 AM
^
 
Oh, that's right. I broke compat with < 2007 at work, not RD.
 
TBH, 2007 and earlier are kind of doomed.
no, wait, they are doomed.
 
IDK, it's good for ransomware.
 
3:45 AM
we need more of ransomware.
 
Hmmm...
        switch (int.Parse(vbe.Version.Split('.')[0]))
        {
            case 6:
                return DllVersion.Vba6;
            case 7:
                return DllVersion.Vbe7;
            default:
                return DllVersion.Unknown;
        }
Reflection on the vbe instance to see if it's from the VB6 namespace?
Or is that too hacky?
 
1) this is backward
case 7 shoudl come before case 6
 
Why?
 
more likely
 
3:48 AM
2) we already have vb6provider andvbaprovider
so those should provide us that information already
 
That's such a micro-optimization you'd need a microscope to see it.
 
and also to avoid loading vbe6 in Office 2016
not even thinking of optimization
only to avoid wrong selection just because we happened to find it
uh.
no, ignore what I just said.
 
That's just asking the VBE what it is.
 
^
realized that too slowly.
eh. This author of the code is a hack.
so for the 6 case, we'll have to somehow query if we have vb6provider instead of vbaprovider or some property somewhere
hmm need to check if the guid are different for IVBE interface.
if they are, that would suffice.
 
Too hacky?
return vbe.GetType().Namespace?.EndsWith("VB6") ?? false ? DllVersion.Vbe6 : DllVersion.Vba6;
Other than the reversed values, that is...
 
3:54 AM
one thing I don't like is that Vba6 and Vbe6 is too subtle
I would prefer DllVersion.msvmvb6
ugly name yes but less likely to trip up
RE: the namespace, that's good enuff for me.
 
vbe*.dll depend on msvmvb6 too though.
vba98?
 
vb98 would work
why must build take so forever
 
I had a build hang this morning because I had a designer open that was picking up a change.
 
@this <compiling.xkcd/>
 
groans
 
4:00 AM
:)
@this for a VBA dll?
 
no for when VB6 is running
because from what I saw, it might not necessarily load the vbe6.dll at all
 
vb98 works indeed
 
Well crap. WTH does it keep it's settings in the registry?
\Software\Microsoft\Visual Basic\6.0 it is.
@this What is this registry key used for? private const string Vbe7SettingPath = @"HKEY_CURRENT_USER\Software\Microsoft\VBA\7.0\Common";
Mine is 7.1
 
that's to get to the VBE settings
in particular the lame Compile on Demand setting
 
Visual Basic\6.0 doesn't have a Common node.
 
4:08 AM
AIUI, this is 7.0 even if you're using 7.1
 
I don't have that in my hive though.
 
and you have 7.1?
 
Huh. Apparently the VBE isn't too picky about where it loads addins from either.
 
hmm
 
4:13 AM
lol, wut?
well, keys are just... keys.
i am sure vb6 doesn't know there's addins64
 
VBE\*\Addins?
 
OR it's probably doing a wildcard match addins*
who knows.
As a test change your COD
close it out
 
Backward compatibility probably.
 
then see what changes in that folder.
 
My COD?
Sounds fishy.
 
4:15 AM
lol
Compile on Demand setting
really, any IDE level setting.
 
Ah, right.
Yep, it's under the 7.1 tree.
 
damn
my research was flawed then
i was led to believe that it would always end up in 6.0 and 7.0
without regards to the minor.
that might explain some odd report where they complained about not getting the expected warning regarding compiling before parsing.
 
Yeah, that would do it.
 
Gonna remember - VBE is a bug.
blah the hacks didn't work. I'm going to just cram EasyHook files in for now.
 
VB6 doesn't seem to have any of those keys btw.
 
4:23 AM
wut?
so it doesn't even use the registry?
could it be stupidly putting it in wow64node subtree?
 
I don't think so. Does VB6 even have compile on demand or background compile?
 
IIRC it does
although, I haven't used it in quite a while
 
it should have...
yeah it does
i'm looking at it
Tools -> Options
 
Yep, it does.
 
under General
 
4:29 AM
OK, now to find out where it's hiding them...
Ctrl-F{un} in the registry.
 
good grief
stupid ms
HKEY_CURRENT_USER\Software\Microsoft\VBA\Microsoft Visual Basic
that's where they are
 
Well FML. It's a per-user setting for VB6.
Computer\HKEY_USERS\S-1-5-21-292160770-1788880404-2744736988-1001\Software\Micro‌​soft\VBA\Microsoft Visual Basic
 
Thanks, MS for making it easy and fun to find!
@Comintern see above. ;-)
 
Ah, your F3-foo is faster than mine.
OK, so that should sort VB6.
 
4:32 AM
so that's 3 different places for settings
rooty-tooty.
 
What about something like this for the VBE?
private const string VbeSettingPathTemplate = @"HKEY_CURRENT_USER\Software\Microsoft\VBA\{0}\Common";
_activeRegistryRootPath = string.Format(VbeSettingPathTemplate, vbe.Version);
 
but VB6 doesn't end in Common
this would be fine for all versions of VBA, though.
 
That's just for VBE - VB6 has its own.
Problematic for WriteAllRegistryPaths though.
6.0, 7.0, 7.1 the only ones we know of?
 
AFAIK, yes....
 
4:38 AM
OK, I'll go with that for now then.
 
the logic w/ the WriteAllRegistryPaths was to ensure that all versions are consistent. Not best UX but seems the least worst
i would have loved to just directly flip the bits in the VBE's memory but....
 
PR inbound. I might have missed something though.
 
> Closes #4516
> This is by design. MCVE:

```vb
Sub test()
foo = 10
Debug.Print foo
foo = 27
End Sub

Property Get foo() As Long
foo = 42
End Property

Property Let foo(ByVal rhs As Long)
Debug.Print rhs
End Property
```

If you put the caret on the `foo` of `foo = 10` in the `test` scope, you'll see "2 references" in the RD toolbar, with the info label saying "projectname.modulename.foo (property let accessor)" - selecting the `Property Let` accessor gets you the `Proper
> This is by design. MCVE:

```vb
Sub test()
foo = 10
Debug.Print foo
foo = 27
End Sub

Property Get foo() As Long
foo = 42
End Property

Property Let foo(ByVal rhs As Long)
Debug.Print rhs
End Property
```

If you put the caret on the `foo` of `foo = 10` in the `test` scope, you'll see "2 references" in the RD toolbar, with the info label saying "projectname.modulename.foo (property let accessor)" - selecting the `Property Let` accessor gets you the `Proper
 

« first day (1622 days earlier)      last day (1558 days later) »