RELOAD!

[rubberduck-vba/Rubberduck] 2 opened issues. 4 closed issues. 15 issue comments.

[Zomis/FactorioMods] 10 commits. 507 additions. 107 deletions.

@IvenBach At home VS Community 2017 Version 15.6.1 builds without any problems. :pats-on-head: You were a good boy and tried. Not your fault.

Could be the VS at work that's screwed up.

In which case.....

Uninstall VS then reinstall?

Huh. I'm on 15.8.8

Then my copy might be FUBARD

IDK. If I can build on 15.8.8, it might been the same thing I experienced few days earlier with my PR

the merge went sideway in all kinds of way

I ended up making a new branch from the commit prior to the failed merge commit, re-merging, then push --force to my origin

I tried that and still got problems at work.

Just pulled off origin and built without a hitch at home.

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #4444: Issue4282 import module folder annotation

[rubberduck-vba/Rubberduck] bclothier created pull request #4473: Fix up the Dispose methods to merge bclothier/Rubberduck/FixComSafeDisposal into rubberduck-vba/Rubberduck/next

> Thanks to @retailcoder for pointing out the little whoopsie I left in the ComBaseSafe regarding dispose.

@Comintern did you fix up the stubbase already?

I haven't - I've been playing around with that inspection.

Ok. going to fix that

That might need a general "what dll am I using" function - IIR that isn't the only place we have the dll name hard coded.

yeah 23 errors

I'm going to add those to the VBERuntime -- that's what it's for

Just so I'm not confused -- the delegates in the fakes are what we stub for the actual call, right?

Yes. We hook the entry point in the dll with EasyHook, and then that calls the delegate.

The delegate can optionally pass the call to the actual dll entry point (if we're only tracking use, for example), or it can provide the return value.

right. so I don't need to fix that; only the extern and the calling. those will be ctor-injected w/ the VBERuntime class

Yeah, the only thing that should need to change is the dll name that EasyHook targets.

[rubberduck-vba/Rubberduck] build for commit b7293415 on unknown branch: AppVeyor build succeeded

Oh. No wonder Mug didn't like Solution Explorer on the left side. It's on the right by default.

gee. i'm finding it hilarious that there's so much difference between the native functions and how they are represented in VBA... rtcKillFiles for Kill statement. WTF?

Reinstall to previous version ruled out VS being the cause.

FWIW, my solution explorer is on the left.

this you got any other suggetions as to how to fix the broken metadata file message?

But I assume that's because I'm just a filthy heathen.

I've nuked both VS and RD from orbit and the issue persists.

TBH, no. I just whacked it hard enough - I already told you what worked for me the last attempt:

[rubberduck-vba/Rubberduck] build for commit 4ca6d8ab on unknown branch: AppVeyor build succeeded

I'll try that once last time.

take extra care with the merge, though.

I'll try.

Somethings really funky. Can't even do a straight pull off next and build. I get errors.

@IvenBach Deleting Rubberduck.SourceControl/SourceControlText.cs.resx now lets it build. Time to test against a git pull upstream next and conflict resolution.

Pulling from next, resolving conflicts and attempting to build causes a persistent break that apparently can't ever be fixed.

Even git reset --hard HEAD~1 to obliterate any changes makes no difference. Nor does changing the branch to a previously passing branch.

Cleaning and building has non relating items in XAML begin breaking.

git status reports a clean working tree.

To be clear - if you git checkout -b Test --track rubberduck-vba/next, do you get problems?

@Comintern the easyhook declarations being statics are an issue - any reason why they can't be static?

@this Confirmed.

@this You can't use the DllImport decoration with an instance.

Executed that code. Immediately built and that's the resulting errors I get.

@Comintern that's not the issue

@IvenBach that's even after doing a clean & rebuild?

@this Which static are you referring to?

this is what i want to do....

The ProcessAddress?

private readonly IntPtr ProcessAddressString;
        private readonly IntPtr ProcessAddressVariant;

        public Environ(IVBERuntime vbeRuntime) : base(vbeRuntime)
        {
            ProcessAddressString = EasyHook.LocalHook.GetProcAddress(VbeRuntime.DllName, "rtcEnvironBstr");
            ProcessAddressVariant = EasyHook.LocalHook.GetProcAddress(VbeRuntime.DllName, "rtcEnvironVar");

            InjectDelegate(new EnvironStringDelegate(EnvironStringCallback), ProcessAddressString);
            InjectDelegate(new EnvironVariantDelegate(EnvironVariantCallback), ProcessAddressVariant);

the ProcessAddress*** at top are originally static

Ah, that should be fine. The ProcessAddress*** are basically just a pointer.

but since the VbeRuntime is being provided, and it's an instance,

ok just making sure there wasn't a reason to not do it

That's more or less the stored entry point into the dll.

yeah

@this Even after a clean and build, yes.

don't like that we'll be reinitializing this for every instance of the fake/stub but other ways would be just kludge, I think

Although, I may need to check and make sure that isn't injecting multiple delegates if it isn't static...

Oh wait, that shouldn't matter. It needs to multi-cast anyway.

if that comes to that, I guess it'll have to be something lame like private static foo = null; and then if foo == null { foo = EasyHook.... }

(idk if there's a static version of Lazy<T>)

The relevant code is var hook = LocalHook.Create(procAddress, callbackDelegate, null);

yeah

That's what registers the delegate. Even if the ProcessAddressen are instance, they'll all be the same value.

ok, not too bad

'sall good.

@IvenBach just to be sure - you're home, right?

this isn't work still, right?

OK, good

If your home box is building fine with the same source, just copy your entire home directory to your work machine (outside of git).

and that is 15.8.8, the same as mine.

hmmm. I'd try that.

Folder copy can work wonders. I used that to solve some brain-fuxing issues with npm at work.

I uninstalled 15.8.8 at work and installed 15.6.7 to be sure it's not the version that's causing the proplem.

fascinating.

Stupid PCV recall. I need to call my BMW dealer tomorrow...

...in that the engine under recall doesn't have a PCV. I suspect the part that I need to replace is the one under recall...

@Comintern just curious - seems not all fakes/stubs actually use VBE's functions. Why?

(InputBox being one)

@Comintern In progress. I hope this magically fixes it.

@this Those are pass-throughs. They're for tests that assert the function is actually called.

but the others that do calls have pass-through, too

...or to count the number of calls.

They're optional. If you fake a return value, you get that back. If you don't, the method is actually called and the hook just tracks the parameters passed and number of times it is called.

For example, you can assert that when MsgBox is called, the 3rd instance has a specific caption.

bad example, but to the point

It's driven by SuppressesCall IIR.

See FakeBase.TrackUsage and FakeBase.TrySetReturnValue for details.

@this OK, missed the point of the question there. A Stub is analogous to a Sub. A Fake has a return value. If you stub something, there isn't any reason to call the function, because you're bypassing the functionality.

ah, right

yes, that's what I was wondering about. Thanks!

Also, calling InputBox and MsgBox would display the dialog, so those ones shouldn't ever be invoked.

oh duh.

Yes, we totally don't want that

Hmph. Painted myself into a corner.

The FakesProvider is COM-visible so must be parameterless and can't be serviced with CW. (In fact, none of the classes in the RD.Main may be and shouldn't be.

And to create an instance for IVBERuntime, I must have IVBE

One way is to gasp create a service locator internal to the RD.Main from the Extension.cs.

that way, the IVBE can be provided to them without changing the client's COM code.

I have no problem with a service locator. The other option is to only expose the interface instead of the coclass, but that's a breaking change.

and that's no-deal for me

^

This must not break.

SL it is then

May Mat forgive me for what I'm about to do.

Better to just break interfaces once, like in the next release to main when we unfuctor #4172...

I want to use the oleaut functions to check permissive asserts. That should resolve the issue once and for all.

@Comintern got a kick out of your comment on number format - like, d'oh. tho I assume it's not what OP actually wanted...

LOL. Because if OP adds another row, it's supposed to be another format?

no I assume OP actually wants to discard the time portion.

A full copy of Rubberduck from my home to work enables a build without any errors.

but maybe I'm mistaken

Formatting should do that. The example data in the question has 00:00:00 time values anyway - I took it as merely a formatting issue.

@IvenBach +1

I'm just worried that doing anything will mess it up.

Not in Column A tho...

@BigBen If the OP really wants to get rid of the time values, that's just a simple Fix(dateVariable) call.

Doesn't solve the formatting issue though.

agreed

BTW, this was a classic too...

hahahahah yeah

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #4444: Issue4282 import module folder annotation

@Duga Need to figure out how to squash work fixing commit into pre-merge commit.

[rubberduck-vba/Rubberduck] build for commit 556a3cef on unknown branch: AppVeyor build succeeded

Hi

I am facing one issue regarding accessing c# web service using http rest endpoint

web service call only works with fiddler

CORS is enabled but api works when fiddler is capturing requests.

@Karthikvenkat86 Welcome to the pond.

Pretty sure the other ducks are nesting and asleep right now.

#TIL I don't want to squash a commit after doing a merge into a commit that was done before the merge. 240 commits was no small number to rebase even though only 10% of those had conflicts...

I now know I can do a git rebase -i HEAD~# and that I don't want to do it again.

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #4444: Issue4282 import module folder annotation

[rubberduck-vba/Rubberduck] build for commit b9a8b137 on unknown branch: AppVeyor was unable to build non-mergeable pull request

BUILD FAILURE!

@IvenBach You thought you could do a rebase.

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #4444: Issue4282 import module folder annotation

@Duga Thou shalt not git rebase -i after merging conflicts. :barf: lesson learned on that...

[rubberduck-vba/Rubberduck] build for commit 97dd065a on unknown branch: AppVeyor build failed

BUILD FAILURE!

C'mon Duga, gimme a break. :hangs-head:

New plan of attack for tomorrow. Cherry pick away my update onto a branch created from upstream next.

@Pond Thanks to all that helped me today. I guess this is a trial by fire/failure.

</iven>

@IvenBach You have copied over your files now anyway, but why was there a Rubberduck.SourceControl on your work machine? That has died ages ago.

@Karthikvenkat86 What language are you using to access the API?

@Vogel612 I think we broke the EasyHook with the new csproj format. Originally, we were copying over the EasyHook32.dll and EasyHook64.dll, among with few other files. Those are found in \Rubberduck\packages\EasyHook.2.7.6684\content\net40. Those aren't copied over to the output of Rubberduck.Deployment and they need to be for EasyHook to work. What would be the best way to remedy that?

Add them to the project by explicitly referring to them, I guess.

EasyHook should be referenced as PackageReference items

I assume we could add a None element with CopyToOutput set to true pointing to the relevant locations

going to try PackageReference first and see if that suffice. Don't wnat to hardcode the versioned path

We do have the PackageReference thing already

that's what the migration of NuGet packages did...

I assume that are also carried forward via ProjectReference

they should be, yes

in this case, only the EasyHook.dll get copied to the output of Rubberduck.Core and Rubberduck.Main

which is then correctly copied over to the Rubberduck.Deployment

that would explain the issue

the PR mentions EasyHook and Fakes in passing twice...

I'm kinda not surprised that something broke ...

Unfortunately, we need the EasyHook**.dlls in the contents. Not sure exactly why/what but I guess we'll have to manually copy those

I assume it's because x86 vs x64

but yea....

hmm that is very interesting. @Comintern probably will want to see this.

'@TestMethod
Public Sub TestMethod1() 'TODO Rename test
    On Error GoTo TestFail

    'Arrange:
    Fakes.Date.PassThrough = True

    'Act:
    Debug.Print Date ' OK

    'Assert:
    Fakes.Date.Verify.AtLeastOnce

TestExit:
    Exit Sub
TestFail:
    Assert.Fail "Test raised an error: #" & Err.Number & " - " & Err.Description
End Sub

'@TestMethod
Public Sub TestMethod2() 'TODO Rename test
    On Error GoTo TestFail

    'Arrange:
    Fakes.Now.PassThrough = True

    'Act:
    Debug.Print Now ' OK

Calling the Date calls the Now indirectly. Thus, when faking them both, Bad Things Happens™.

grumbles grumbles why won't stupid VS actually do what it's told

I've always found that the problem with computers is that they do exactly what they're told to do, even when it's subtly different than what you want them to do.

That said...

grumble grumble grumble why won't SSMS prompt me with parameters when I hit ctrl-shift-space?!

In my SQL table, I have 2 columns:

ColA [bit]
ColB [bit]

I can Select ColA | ColB as Flag to have Flag = 1 if either 'ColA' or 'ColB` is "set", correct?

I see the problem. It's a two-bit. You get what you pay for!

Yes, that's exactly the case. see:

when there's a WHERE clause that's preventing return of the data you're expecting to see, the new part of the SELECT doesn't seem to work... :/

Such is life.

...when you haven't yet had enough Java coffee

in end Content wasn't suffice by itself. I had to add a Target, too.

@this See:

gets a lotta mileage outta that comment

[rubberduck-vba/Rubberduck] inDeev opened issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] daFreeMan created comment on issue #4474: Feature: Show/Hide/Veryhide sheet

@this Crap. Is it rtcGetPresentDate that's calling rtcGetDateVar, or is it the other way around?

[rubberduck-vba/Rubberduck] retailcoder edited issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] daFreeMan deleted comment on issue #4474: Feature: Show/Hide/Veryhide sheet

@Duga @MathieuGuindon's method works better. @FreeMan's method is a non-admin's kludge

@Comintern Date -> Now, so that'd be rtcDateVar -> rtcGetPresentDate

BTW, I just verified this is a pre-existing issue. (tested on next)

Yeah, I don't doubt it.

[rubberduck-vba/Rubberduck] Vogel612 edited issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 added label enhancement to issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 added label user-interface to issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 added label feature-code-explorer to issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 added label up-for-grabs to issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 added label difficulty-02-ducky to issue #4474: Feature: Show/Hide/Veryhide sheet

@Duga that doesn't work, because the image is somewhere else

Yeah.. Having a hard time fixing it with phone

I got it

[rubberduck-vba/Rubberduck] bclothier created pull request #4475: Update Stubs & Fakes to use VBERuntime class to merge bclothier/Rubberduck/FixStubBase into rubberduck-vba/Rubberduck/next

to abstract the loading of correct VBA.dll file. Accordingly the extern declarations were moved out of the stubs/fakes into the VBERuntime6 and VBERuntime7. implementations. This unfortunately means the stubs & fakes now depend on VBERuntime which in turns depends on the VBE. Because stubs & fakes are not part of CW (and they never should be) we cannot dependency-inject them. Furthermore, we do not want to change the interfaces nor existing unit tests code. For that reason, we create...

VbeProvider (note the consistency in naming, har har) service locator which is internal to the Rubberduck.Main project and used only to support the stubs & fakes. I've put in a large comment about how evil it is, and that it should be limited in scope.

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #4474: Feature: Show/Hide/Veryhide sheet

@Vogel612 thanks

@Duga that makes it a [status-declined], doesn't it?

[rubberduck-vba/Rubberduck] bclothier opened issue #4476: Some fakes do not play well together

[rubberduck-vba/Rubberduck] bclothier added label difficulty-03-duck to issue #4476: Some fakes do not play well together

[rubberduck-vba/Rubberduck] bclothier added label bug to issue #4476: Some fakes do not play well together

[rubberduck-vba/Rubberduck] bclothier added label feature-unit-testing to issue #4476: Some fakes do not play well together

@Vogel612 IMO, yes. That property isn't really a VBA thing.

@Vogel612 agreed

[rubberduck-vba/Rubberduck] Vogel612 added label status-declined to issue #4474: Feature: Show/Hide/Veryhide sheet

[rubberduck-vba/Rubberduck] Vogel612 closed issue #4474: Feature: Show/Hide/Veryhide sheet

"Nägel mit Köpfen machen" :)

If Google translation is accurate, sounds... painful.

My German is rusty, but is that roughly "pound a nail with your head"?

yea, but it's an idiom

like hit the nail on the head, but more German ;-)

my favorite dictionary suggests the following

better than "pound a nail into your head", though the former may end up as the latter...

@MathieuGuindon That'd be "Den Nagel auf den Kopf treffen"

@Vogel612 aah, makes sense

Interesting - I missed the connotation entirely. German carpenters are apparently pretty hard-core.

99 out of 100 doctors recommends not pounding nails with your head. The 100th doctor was too sick to answer the survey.

lol

the connotation it implies is somewhat similar to "move fast, break things"

@Comintern like this?

lol

[rubberduck-vba/Rubberduck] daFreeMan created comment on issue #4474: Feature: Show/Hide/Veryhide sheet

> Since you're in the VBE anyway, typing Sheet1.Visible = xlSheetVeryHidden in the Immediate Pane isn't too much more difficult, especially with IntelliSense doing most of the typing for you.

[rubberduck-vba/Rubberduck] build for commit 7523788b on unknown branch: AppVeyor build succeeded

@this That's a bit of a dying art since most rough framers use nailers these days...

@Vogel612 ooooh... like MS does with Win10! (ref: @KySoto's post yesterday about the semi-annual "feature" release.)

@FreeMan And with a good compressor, it's more of a challenge to sink a nail in one hit than in 75% of a hit...

@Comintern Compressor? Where we're going we don't need a compressor.

More a tool for "where we're going we don't have electricity" IMHO.

@this You must be a time traveler, I'm only on the 13th Doctor!

Wouldn't everyone be on the same Doctor regardless of where they are in the timeline though?

Wrong kind of doctors. Those surveyed were quacks.

Thought we were the quacks.

Well in that case, take two aspirins and see me tomorrow.

@this thanks, Groucho

@Comintern Yes and no. I'll have to check with River Song to be sure.

Interesting side note: a former pastor at my in-laws church named his latest daughter "Riversong". Yes, that's her first name. Several other Doctor related names were rejected by his Amelia, but they're not coming to mind at the moment. I'm quite certain "Dalek" was not among the options, though.

Dalek sounds like a better boy's name. A more sinister version of "Derrick".

And, since so many Brits pronounce it "Darlek", it's really not that far off...

[rubberduck-vba/Rubberduck] bclothier created project card

[rubberduck-vba/Rubberduck] Vogel612 commented on Rubberduck.Deployment/Rubberduck.Deployment.csproj of pull request #4475: Update Stubs & Fakes to use VBERuntime class

[rubberduck-vba/Rubberduck] Vogel612 commented on Rubberduck.Main/VbeProvider.cs of pull request #4475: Update Stubs & Fakes to use VBERuntime class

[rubberduck-vba/Rubberduck] Vogel612 commented on Rubberduck.VBEEditor/VBERuntime/IVBERuntime.cs of pull request #4475: Update Stubs & Fakes to use VBERuntime class

[rubberduck-vba/Rubberduck] Vogel612 is bored so why not move a project card

[rubberduck-vba/Rubberduck] Vogel612 is playing around with a project card

[rubberduck-vba/Rubberduck] Vogel612 is bored so why not move a project card

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Deployment/Rubberduck.Deployment.csproj of pull request #4475: Update Stubs & Fakes to use VBERuntime class

[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.VBEEditor/VBERuntime/IVBERuntime.cs of pull request #4475: Update Stubs & Fakes to use VBERuntime class

[rubberduck-vba/Rubberduck] Vogel612 commented on Rubberduck.VBEEditor/VBERuntime/IVBERuntime.cs of pull request #4475: Update Stubs & Fakes to use VBERuntime class

@M.Doerner no idea why it was there.

> That smacks of cargo-cult behavior. You should only be performing this work where it is necessary, and close to the place where it is necessary.

^ Yeah!

I feel like a cult intervention worker sometimes.

lol

@all so - we've been flipping between VBE or Vbe all over the solution. Now is the time to choose the One True Capitalization™. So which will it be.

vbe

:)

Can't. That's what we do use for variables/members. This is more for class names.

e.g. IVBE vs IVbe; VBERuntime vs VbeRuntime, etc.

I chose that because it wasn't on the list of options given.

;)

Precisely why it wasn't given. ;-)

I say it's a legit acronym for our domain. VBE for me.

I'd personally do Vbe so R# stops whinging about it all over the place.

I can't say I have a strong opinion either way though.

TBH me too... but damn it's ugly!

We could just put in a solution-wide ignore

so R# won't ever whinge about it

smacks R# so it stops whinging

Meh, TBH that's less obnoxious than the spell checker complaining that "Rubberduck" is spelled wrong all over the place.

OTOH, "HTML" is "Html" in the framework is it not?

XmlSerializable

Yeah, I think that's fairly standard. Db too.

feels like Vbe would be the idiomatic way to go

By extension, we'll have to do the same things to VBProject and VBComponent....

which is kind of interesting because those wrap the VBIDE.VBProject/VBIDE.VBComponent

#FML

Ok how about ignoring capitalisation issues in VBEditor, and then renaming our interfaces to drop the pseudo-Hungarian VBPrefix?

WTH? That seems to be a bit of relevant information there, donchathink?

That's what I was inclining toward, yeah.

Is this going to cause everything to merge conflict?

Oh, hell, yeah.

That's a ton of file renaming.

The third option would be to let the sleeping dog lie.

(and silently curse to oneself for the inconsistency)

Why silently?

Ok. Silent's optional.

Cursing, not so optional.

lol

[rubberduck-vba/Rubberduck] JosephIaquinto starred us

#Compromise: VB* => classes that directly wrap VBIDE.VB*. Vb => classes that we made up ourselves to extend, enhance and extinguish VBIDE?

LGTM

we should probably be documenting this somewhere

Which means I only need to change the VBERuntime - Vogel suggested VbeNativeApi but I wonder if it's better as VbeRuntimeApi - not sure Native convey the context.

mornin people

I guess it can go there

which incidentally is kind of buried all way to the bottom....

@this You might as well catch VBENativeServices.cs while you're in there. That one should be relatively small in impact.

Ah that's why I was not comfortable with Native

But yes, I can do that, too.

VbeUnmanagedServices?

the Native term is just too broad.

I think it has the same problem

VbeGlobalGodObject?

lol

What about something like VbeWin32InteropServices?

why can't it be VbeMessagePumpService?

That might be a little too specific - it doesn't just handle the message pumps.

VbeWindowManager?

[rubberduck-vba/Rubberduck] jhiston opened issue #4477: Code Explorer - Option to have module show up in multiple places (Feature request)

VbeWinApiBridge?

@MathieuGuindon Documented here, what more do you want?

That's ugly as sin.

yeah and tells us nothing about what it's briding -- Vbe and WinApi are two big broad object

@Duga wut?

Heck, I might just leave it at VbeNativeServices for now.

+1 #NamingIsHard

@Comintern multiple @Folder inheritance?

I think that would be a mess.

A dependency view is something fundamentally different from a project/code explorer

Different @Folder views I could understand.

I would rather implement this as a separate view, instead of overloading CE, TBH.

^