We had an 8yr old at my HS. His mom was with him often. The other half he was riding around on other students shoulders, most of the time the football linebackers.
yeah, was considering skipping summit 2020, but now if I can get my mom to pay for the trip, I don't mind having her wandering in Seattle while I'm in sessions :)
and in a dream world, selecting a string literal in the editor and bringing up the regex tool would pick up the string literal and plug it into the pattern field
@Hosch250 it's good, but the problem with ' ' is that it works for a space, but not so much for a non-breaking space, or other hardly-representable characters
and then we could have a "Explain this regular expression" command that's enabled when a regex literal is right-clicked... although, that might be over-the-top (how does R# do it?)
anyone got time to try a quick repro? don't wanna raise an issue if it's just my dodgy dev build...
> 1) Open CE 2) Right click a node, go to Add submenu (all is well) 3) Click Add button in the CE toolbar (all is well) 4) Right click a node, go to Add submenu (boom - all entries are invisible)
> **Rubberduck version information** Version 2.4.1.37223 OS: Microsoft Windows NT 6.2.9200.0, x64 Host Product: Visual Basic x86 Host Version: 6.00.8176 Host Executable: VB6.EXE (but repro'd in VBA too)
**Description** The items in the Add menu in the Code explorer are invisible (albeit with space reserved for them) under certain scenarios.
**To Reproduce** Steps to reproduce the behavior: 1. Go to Code Explorer 2. Right-click a component node, expand the 'Add' submenu 3. Click
@this any other ideas how I can solve the AV on component.remove on VB6? Tried suspending parse, no change. I think the ProjectRepository.Components collection is not updating early enough. So I tried refreshing the project repo after the remove, that just results in all the project RCWs getting disconnected :-(
Its either the projects repo, or the CE node tree. One of them is just too slow off the mark...
Annoyingly, it works fine through the PE. CE notices the ComponentRemoved event, refreshes and removes the node, no AV in sight...
@Vogel612 what I'm thinking of is more along the lines of populating the model from a selected string literal, showing the dialog, user edits the pattern, okays the dialog, and the updated pattern replaces the in-editor selection
all the other resource files have been adjusted to work with the new MSBuild, but the AssistantResources haven't been changed since the csproj migration
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=h1) Report > Merging [#5044](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/0a25ee7ba648f04c4e930bdfd12a982e16b22af4?src=pr&el=desc) will **decrease** coverage by `0.05%`. > The diff coverage is `23.66%`.
@this It's not yet. I think I might end up needing to pre-emptively remove the being-removed component from the node's VM, or mark it in some way so that all COM access stops. But that's a Monday commute problem... If I make no headway, I'll open a draft PR.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=h1) Report > Merging [#5044](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/0a25ee7ba648f04c4e930bdfd12a982e16b22af4?src=pr&el=desc) will **decrease** coverage by `0.02%`. > The diff coverage is `28.21%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=h1) Report > Merging [#5044](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5044?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/0a25ee7ba648f04c4e930bdfd12a982e16b22af4?src=pr&el=desc) will **decrease** coverage by `0.02%`. > The diff coverage is `28.21%`.
having said that, I think I'm making headway (couldn't put it down)
ProjectsProvider.Components(/*QMN*/).Remove()is unsafe. ProjectsProvider needs an explicit RemoveComponent command, which does some very careful locking. I'll be marking the PR as [review-requested] :-)
OK, got it working reliably. Need to check my threading is solid, and I have no idea how usings are supposed to work in ProjectProvider. These are all Monday problems :-)
I know consumers are not supposed to using stuff they get from the provider, but not sure if that applies to the collections held inside the provider.
looks like they shouldn't either
ok, so sneak peek - this is in PP:
public void RemoveComponent(QualifiedModuleName qualifiedModuleName)
{
EvaluateWithinReadLock(() =>
{
if (_components.TryGetValue(qualifiedModuleName, out var component))
{
ExecuteWithinWriteLock(() =>
{
if (_projects.TryGetValue(qualifiedModuleName.ProjectId, out var project))
{
using (var components = project.VBComponents)
{
components.Remove(component);
ignore the return, that's a hack, will sort that :-)
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5047?src=pr&el=h1) Report > Merging [#5047](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5047?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/0a25ee7ba648f04c4e930bdfd12a982e16b22af4?src=pr&el=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `n/a`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5047?src=pr&el=h1) Report > Merging [#5047](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/5047?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/0a25ee7ba648f04c4e930bdfd12a982e16b22af4?src=pr&el=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `n/a`.
Yoshi was ground into sausage when they last made lasagna. Luigi previously succumbed to a bad case of lead poisoning from crossing the Italian mob. Sad story both really.
for the provider itself, yes but the members in the collection will be governed by the provider itself, so the prvodier also owns its collection members
I can't help but thinking that the provider is a hint at an even-more-awesome solution, where all COM access is abstracted and managed, and clients access it through expressions rather than direct access. I also wonder if that is part of solving for serving 3rd-party add-ins...
Ideally a client should never have to wonder if they should Dispose or not. Indeed, the wrappers wouldn't even expose IDisposable to the outside world.
My dream is that add-ins never have to worry about the toxic waste of COM. That may or may not be achievable. Jury's out.
if there's an add-in, IMO, the only access should be via provider. I guess we would also need to hide the IDisposable to outside users
in fact, I think you just pinpointed why this is confusing.
if we modified the SCW interfaces so that the provider provided a non-disposable interface while internally handled disposable interfaces, the users would understand it's not theirs to dispose.
OTOH, we are supposed to have the IDisposableAnalyzers but they have yet to add the annotations we need....
unrelated: My working assumption is that @ComIntern has signed another NDA, perhaps (probably?) with the same outfit as last time. @MathieuGuindon are you able to confirm or deny? If you're sworn to plausible-deniability, an IDK is perfectly fine too :-)
@this If they provided non-disposable interfaces, the users would not be able to dispose, and that would be correct and appropriate. Unless I'm missing something?
My intuition says it's borderline... If there were a general solution to disposal of RCWs, MS would have done it. But... we know the exact scope, and perhaps more importantly, the exact lifetime of these particular COM objects. It might be possible to manage disposal for 3rd parties. Maybe.
@M.Doerner what do you think of the idea of creating non-disposable SCW interfaces and making the disposable SCW interface private or at least internal?
The issue isn't whether it's readonly but rather that we shouldn't return SCW that has since died (e.g. it was removed in response to a VBIDE event)
That's what hte provider odes basically - monitors for any events that might need it to refresh its SCW collection so we don't have to worry about having a stale SCW
The ProjectProvider and the CodeExplorer were both listening for the same ComponentRemoved event. Which one won determined whether there would be an AV or not...
@M.Doerner but the problem is that, whilst the collection item may be valid when the PP collection enumerator supplies it, it's in the process of being destroyed when CanExecute tries to query it.
=> AV
hence my solution of requesting COM actually remove it, and we delist it, all under lock, per my code ^^
Incidentally, I think this is a problem which is unique to the removal of components. Additions and modifications of components will eventually feed through to listeners, and all will be well. But with removals, we have VMs that are bound to, and end up calling methods on, COM objects that may-or-may-not still exist, based on timings.
It might not be worded directly as "you can't do OSS!"
but i can imagine NDA having language like "if you share code anywhere, we assume you have stolen from us and we will sue the pants and the ass off you!!!!"
@IvenBach NDAs are custom contracts between one entity and another. Usually BigCorporation => Individual. Or possibly BigCorporation => Private Service Company. Either way, have you seen the Simpsons sketch where Mr. Burns lawyer-pack file in? That's what you're up against. It doesn't matter if you're right.
VBA Rubberducking
VBA Rubberducking