« first day (1628 days earlier)      last day (1552 days later) » 

9:00 PM
yes recentish => 1-2 months ago, IIRC
 
@Comintern That bug looks to me as if somebody disposed a component from the ProjectsRepository.
 
@M.Doerner not if it means a change throws off the selections- e.g. double click DoSomething and you're 5 lines under it because the code was changed.... wouldn't make us look good =)
(unless I'm misunderstanding something)
 
Huh, how can there be a problem with a selection?
I am talking about the feature to be able to specify 3rd party projects as built-in.
They will be treated like COM references.
The question is whether they get the extra feature of being refreshed should you actually change them.
 
@Vogel612 didn't know that.
 
so we don't navigate them, and skip inspecting them, and now this is about whether their new members added since they were first loaded show up in CE when we reparse?
 
9:06 PM
They will not show up in the CE either way.
The scenario where this would make a difference is when you change the built-in project, e.g. rename a member, and then reference the changed member from your ordinary project.
 
@M.Doerner speaking in general terms, when you mentioned “treated like COM references” would this imply RD can initiate some message pump conversations back and forth?
 
No
I mean this in how we treat it internally.
 
Cool. Just checking that context.
 
@M.Doerner ah. But we don't allow refactoring built-ins, so that would be the user renaming a referenced method manually? I think we might want/need to track it then, yeah
The RD selection bar showing the old name would be awkward otherwise
 
On the other hand, if you specify something as built-in, we could take the position that we can assume it will not change during a session.
That would save us from getting the content hash of all modules in the built-in projects.
 
9:15 PM
is it really costing that much though?
maybe let the user decide?
(through settings)
(and default for performance, I guess)
 
TTFN
 
I kind of do not like the idea with the setting.
 
ahhh git yer turkey day here at my work
 
From the functionality side, that would be nice, but from the implementation side, it will be a PITA.
 
its a nice frituesday
 
9:23 PM
Moreover, there is no good way to react when the setting gets changes in the middle of a session.
 
It'll be a FriWednesday tomorrow.
And they might let me out at 3PM.
 
I'm strongly agreeing with Max here..
 
@KySoto Lots of businesses seem to do that now.
 
@M.Doerner Yep.
 
9:26 PM
fwiw that's a case for a project metadata file
which is entirely another PR. It can wait for that PR.
 
I will start off with keeping them out completely. If we want the other option or the setting later on, what I will implement now will not cause too much trouble if I do it in the right spot.
I just needed to know how to handle them, because I will set up the cache invalidation already in this PR.
To get the 3rd party project feature in, no more changes to the ParseCoordinator should be necessary.
 
worst case, err on the side of invalidation. It's not like reading these locked projects takes ages
 
It is not the locked projects; those are easy.
You cannot relock a project from the standpoint of the VBE.
Once unlocked, the VBE always returns it as unprotected.
The problem is with huge unprotected 3rd party projects.
 
Do we detect when it becomes unlocked?
 
Yep
It is a project event.
And the projectId changes.
 
9:30 PM
ah, Added/Removed.
OK
 
I use the method for references to generate a projectId for the loced projects.
 
@Hosch250 Its nice, though this turkey is going to my mother in law
 
@KySoto Don't eat too much turkey and fall asleep.
#TIL you can enter unicode chars in via their code: superuser.com/questions/1204586/…. Just need to edit registry.
 
10:15 PM
bah, next won't build...
 
what's the error?
 
> Two inspection issues with this:

```
Option Explicit
Sub test()
ReDim myTestVar(0 To 0)
End Sub
```

1. `myTestVar` IS a local variable but RD incorrectly flags this with error:

> "Local variable 'myTestVar' is not declared."

Perhaps a warning/suggestion to explicitly declare the variable would be more useful.

Interestingly enough, RD fails to warn that the variable is implicitly variant.

2. Also, in my opinion, allowing `ReDim` (i.e. "dimmed again") to be used as a d
 
dunno, updating vs atm
think it was complaining about resx though
 
I think I have found the problem with the quickfix and the components: github.com/rubberduck-vba/Rubberduck/blob/…
That is from part 2 of the Com Cleanup PR.
 
and sure enough: it has a TODO :D
 
10:23 PM
The problem is not the old TODO, but the new using.
 
A bit of irony in it being in the IgnoreOnceQuickFix.
More like HardIgnoreForever.
 
10:44 PM
Today is dragging. Someone make it go by faster.
 
The only way I know how to do that is travelling east.
 
dragging? Listen to Smetana. That's a whole new dimension of "dragging"
I've had four minutes straight of "finale" in "Vlatva"
 
ok next built
but dang it takes an age to build now..
 
11:09 PM
That is because all those MS code analyers are running on every build.
 
Little River Band is making the day go by much faster.
 
@MathieuGuindon is that OK?
 
@M.Doerner I see. I will fix that.
 
actually, this one's better:
 
Nice!
 
11:23 PM
pics or it didn't happen it definitely happened :-)
 
11:49 PM
@mansellan that's awesome!
 
the duck looks nice in it's 1998 pond :-)
 
Which part of the screen snap tells me it’s good ~confused
 
@PeterMTaylor all of it! none of these toolwindows hace ever been seen (widely) in the VB6 IDE...
 
well, except the properties window. we haven't gotten around to that yet... ;-)
 

« first day (1628 days earlier)      last day (1552 days later) »