« first day (1608 days earlier)      last day (1572 days later) » 

8:08 PM
@M.Doerner Caught up to what you said nearly 2 hours before. Working on this.
I'm just a bit slow on the uptake.
 
So, it seems that setting the error to display Build Only rather than the default Build + Intellisense helps with avoiding showing you bogus errors like missing metadata files
However, 2018 still doesn't update its error list. :(
 
Another RD parse error
similar deal to last time
cept it was (i think) a different path
it was trying to work in a folder that didnt exist
 
add to the bug report you opened?
 
so i manualy created hte folder, and it parsed
 
> I opened the attached log and checked the path it was complaining about, tried to navigate to it, and the folder Rubberduck folder in the temp folder didnt exist. I manually created the folder, and it parsed. RubberduckLog.txt
> Version 2.2.6672.28001
OS: Microsoft Windows NT 10.0.16299.0, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.4711.1000
Host Executable: MSACCESS.EXE

I opened the attached log and checked the path it was complaining about, tried to navigate to it, and the folder Rubberduck folder in the temp folder didnt exist. I manually created the folder, and it parsed. [RubberduckLog.txt](https://github.com/rubberduck-vba/Rubberduck/files/2536247/RubberduckLog.txt)
 
8:22 PM
@this Ok added.
 
:+1:
one more thought, @KySoto -- did you parse while forms were open in form view, rather than design (ditto for reports)?
 
yes. a form was open in form view
but it worked after i created the folder
 
8:43 PM
> FWIW - I think there's some mangling with the HRESULT.

Given this VBA code:
```
application.VBE.ActiveVBProject.VBComponents(1).Export "C:\foo\goo\bar\nothere.txt"
```

We get an error:
```
---------------------------
Microsoft Visual Basic for Applications
---------------------------
Run-time error '50035':

Application-defined or object-defined error
---------------------------
OK Help
---------------------------
```


50035 = 0x0000C373
`vbObjectError` = 0x800400
 
8:53 PM
> FWIW - I think there's some mangling with the HRESULT.

Given this VBA code:
```
application.VBE.ActiveVBProject.VBComponents(1).Export "C:\foo\goo\bar\nothere.txt"
```

We get an error:
```
---------------------------
Microsoft Visual Basic for Applications
---------------------------
Run-time error '50035':

Application-defined or object-defined error
---------------------------
OK Help
---------------------------
```


50035 = 0x0000C373
`vbObjectError` = 0x800400
 
RE: renaming VBE to Vbe, I'm having a bad feeling --- how do we ensure this doesn't result in phantom files once distributed via git? Keep in mind I'm renaming both files and types.
 
It should just "work".
git comes from *nix land, so it sees them as completely different files.
 
for some values of "work". You weren't around when we were chasing away the RetailCoder.VBE that wouldn't die
(in contrast to Retailcoder.VBE)
 
@this In my case, I get the errors because quite a few quickfixes now require less arguments in the ctor and because the Fix method has one additional parameter, the one the entire refactoring is about.
 
@this Only problems that I've ever run into have been switching branches with the Team Explorer instead of from the command line.
 
9:04 PM
@Comintern is there a easy way of getting the raw HRESULTs inside VBA?
 
You mean for the mdi children?
 
no for VBA runtime errors
see above
 
Ahhh... generally you just need to tack 0x8000 on the front and call it hex.
 
yeah normally.
 
For that one, I'd take a look at this: vbaexpress.com/forum/…
 
9:06 PM
(0x800A, no?)
 
Permissions issue?
 
he did create the folder manually
so don't think it's just a permission issue
 
Oh, yeah, I forgot we smoked that in chat.
@this If that's a conforming HRESULT, 50035 = 0x0000C373 makes sense. The high word is not "technically" part of the error code.
In the field of computer programming, the HRESULT is a data type used in Windows operating systems, and the earlier IBM/Microsoft OS/2 operating system, to represent error conditions, and warning conditions. The original purpose of HRESULTs was to formally lay out ranges of error codes for both public and Microsoft internal use in order to prevent collisions between error codes in different subsystems of the OS/2 operating system. HRESULTs are numerical error codes. Various bits within an HRESULT encode information about the nature of the error code, and where it came from. HRESULT error codes...
Something is yanking the lword off before it's displayed.
 
Hmm. but not just the word
it's off by one, too
 
0x800A would be a non-success value (bit 31 is set), and the A should be the "facility code".
 
9:14 PM
so yeah, i manually created the folder because last time
you asked me if i could navigate to the folder that it was having issues at
if i can create the folder, i assume im good
 
No, i mean that the lword of HRESULT returned was 0xC372 --- whereas the VBIDE error equates to 0xC373
 
well that and it worked after i did
thats fun.
-_- not.
 
Yeah, something's failing when creating the folder.
and not detecting that.
 
@this Ahhh, gotcha. That's odd. Facility 10 is "Control", whatever that means.
 
that's why I thought maybe it was something stupid like overflow then appending to some prefix
I remember some years ago I encountered a bizarre HRESULT, which actually turned out to be a benign Access OM error that was esaily handled
they did not jive at all
 
9:18 PM
That would be a pretty severe overflow - that's like an order of magnitude.
 
so I've been suspicious about HRESULT vs. what we normally get via OM.
 
Not suspicious of Access?
They usually make sense coming from Excel.
 
?1004 makes sense?
;-)
 
0x3EC => it's short for Eeeeek!
 
#TIL
 
9:21 PM
#TIMU
Today I Made Up.
 
#TIFFI
 
#TIMMEH
 
9:46 PM
> Addendum:

This is fine:
```
Fakes.Now.PassThrough = False
Fakes.Date.PassThrough = False
```

So is this:
```
Fakes.Now.PassThrough = True
Fakes.Date.PassThrough = False
```

But NOT this:
```
Fakes.Now.PassThrough = False
Fakes.Date.PassThrough = True
```

So though `PassThrough` plays a role, it is only an issue with the fake where the function will end up implicitly calling some other function that's also hooked.
 
Duck check: With pre-compiler directives. Are they entirely stripped out by the IStringParser?
 
> My best guess without have dug around in it is that there's probably some confusion over who is responsible for the memory of the `Variant` that is getting passed around, the wrong dll tries to free it (vbe7, RD, and easyhook are all touching it), and... access violation.

My money is on RD, but the forwarded calls need to be sorted out regardless of the resulting Appslosion because this will also give incorrect testing results due to multiple hooks tracking the same invocation.
[rubberduck-vba/Rubberduck] comintern did something with some project card
 
@Duga Ooops. Wrong button.
 
10:01 PM
The preprocessor we use in the IStringParser send all dead code to a hidden channel. This means that the parser will not see it, but it is still present in the text we get from the rewriter.
Here dead means either being part of a precompiler directive or unreachable according to the currently set compilation constants.
 
I ask since:
Attribute VB_Name = "Module1"
#If False Then
'@Folder(VBAProject)
#Else
'@Folder(IVEN)
#End If
Became Attribute VB_Name = "Module1"\r\n\r\n\r\n\r\n'@Folder(IVEN)\r\n and was surprised not seeing the precompiler directives.
 
They are not in the parse tree, only in the token stream.
 
I think I understand. Correct me if I'm wrong.
#If False Then false under the conditional compilation, but the \r\n does not since it's a valid token for the line.
I'm assuming that's the case for all the conditional compilation since there's 4 newlines before the folder annotation.
 
I do not know the exact setup in the preprocessor, but I think we do this to keep the selections in sync.
 
Selections?
 
10:15 PM
Line and column numbers
 
If we considered the newline as part of the compilation and there is a variable below it, on say line 7, removing it would shift it from line L7C5 to L6C5 and would mess up any rewrite.
 
Exactly
 
We'd then have to shift every location according to that many lines.
mkay
 
Probably
 
At least I'm starting to get a grasp as to what's going on.
 
10:17 PM
To be honest, now that we hide the dead stuff instead of removing it, considering the newlines as dead would probably not matter.
The selection covered by a context is derived from that of the tokens, which does not change when hiding other tokens.
 
:barf: Cleaned solution and forgot about the metadata errors.
Now I can't build.
 
10:55 PM
Duck check: What is the .vs folder?
 
damned if I know
 
I think HOsch said it stores user settings
For one thing if I delete the .vs folder, the next time I load the project, all folders are expanded
I have to collapse the projects, and only then does it remember to keep it collapse next time I reload... until I delete the .vs folder.
 
IIR it stores your IDE state - open windows, etc.
 
^
but if that's what it takes to fix a build problem.... someone goofed up.
 
11:03 PM
developercommunity.visualstudio.com/content/problem/82249/… says "... .vs folder is required by Visual Studio to store opened documents, breakpoints, and other information about state of your solution."
 
read: nuke it at will
 
I've tried pulling RD into a different folder and build but didn't fix it. I'm about to wipe the .vs folder but wanted to educate myself before nuking my foot.
At the very least this little problem forced my hand into learning way more than I thought possible in a couple days.
 
you'll probably forget most of it by half a year's time
but that's not really a bad thing. It's more important that the work of looking it up and the tricks to learning that much so quickly get into your skull :)
 
The crack in my skull help the information get in faster.
 
No luck on .vs deletion.
One less possibility.
 
if you check the output, it's the core that's failing?
 
13>C:\Users\cpaustell\Source\Repos\Rubberduck\Rubberduck.Core\UI\ToDoItems\ToDoExplorerControl.xaml(17,10): error MC3074: The tag 'InvertBoolValueConverter' does not exist in XML namespace 'clr-namespace:Rubberduck.UI.Converters'. Line 17 Position 10.
13>C:\Users\cpaustell\Source\Repos\Rubberduck\Rubberduck.Core\UI\UnitTesting\TestExplorerControl.xaml(20,10): error MC3074: The tag 'TestOutcomeImageSourceConverter' does not exist in XML namespace 'clr-namespace:Rubberduck.UI.UnitTesting'. Line 20 Position 10.
there's text above that but that's the first indication of failure.
 
Rubberduck.VBEEditor/Events/VBENativeServices.cs <== I was afraid of that.
 
11:11 PM
Hullo. WTF is this.
Rubberduck.Interaction > Dependencies > Analyzers
the path has a C:\Foo\Bar\\Buzz\RubberduckCodeAnalysis.dll
could the double `\\` be part of the issue?
 
@IvenBach that shouldn't actually be an issue
 
it's because I added an extra slash
 
@IvenBach chat is a bit of a horrendous pain about backslash
 
but thankfully Windows helpfully pretends that \\ is same thing as \
 
^
 
11:15 PM
^^^ yes it is a pita
well not just Windows. All OS, probably.
 
Seems I made it worse unloading every project and reloading them.
Can't build or clean now.
 
that is puzzling that you are persistently having problems
all on the work, right?
 
Only on work.
 
You can always clean - just delete the bin folder.
 
Might as well ask. What's the difference between the bin and obj folders?
 
11:18 PM
or use the git bash and run rm -r */bin */obj
make sure there's no leading slash though
 
I can get a build started. It's just never finishes currently.
 
@IvenBach binary files and MIDL files IIUC
at least that#d be my first guess
 
don't think C# uses IDL
 
@Vogel612 "remove recursive folders of /bin or /obj"?
 
@IvenBach close, but no cigar
 
11:19 PM
obj folders are just intermediary build files
 
That's just my guess from memory and reasoning my experiences with git.
 
for something something reasons, compilers has to do a multiple pass over the source code.
 
[rubberduck-vba/Rubberduck] build for commit e7e27d40 on unknown branch: AppVeyor build succeeded
 
@IvenBach it's really close
but only using * does not recurse
 
-r is the recursive flag IIRC.
WTF... Why is VS taking minutes to close the projects and shut down?
:grumble:
Something is definitely not right under the hood.
 
11:22 PM
@IvenBach yes, but that controls how rm behaves.
the * controls how the file matching behaviour behaves for rm's "starting points"
so that command line is functionally similar (though not equivalent) to rm -r */bin; rm -r */obj
 
Remove any folders within the directory that or bin or obj.
 
also pretty close, but still no cigar.
 
~.~ You know my pedantry is weak.
 
@IvenBach Historically, the build is divided into 3 steps - precompile (expand macros, process directives, and basically get the "working" source code), compilation (compile the objects), and linking. The reason the linking has to be done last is that the you can't determine the procedure entry points without having compiled. Not sure how much of that is still true for .NET though.
 
the correct answer is: Remove all obj and bin folders that are in one of the current folder's child folders
 
11:27 PM
I see the same meaning in what I said with fewer words :p
 
11:48 PM
What was the fix for all the references with yellow triangles?
 
kicking VS and telling it to look harder?
 
Tried several times.
 
build errors?
if no: proceed to ignore VS being dumb about this
at least that's what I did :D
 
Severity Code Description Project File Line Suppression State
Error Error occurred while restoring NuGet packages: The operation failed as details for project RubberduckTestsCodeAnalysis could not be loaded.
When I try and build it never builds, no output occurs. Never finishes
 
that fixes itself after a restart and then jams back up again
at least that's what happened on my VS, which is ... an old version
 
11:57 PM
Speaking of version... is your VS install up to date?
 
It's on an older version.
 

« first day (1608 days earlier)      last day (1572 days later) »