My current code takes a set of caller information ("calldataFile" or "CD_") and allocates it back to the specific source that it came from into a different file ("Internal File" or "WT_").
The code takes between 72-75 seconds to run for the specific data set I'm testing. Considering that is a...
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4426?src=pr&el=h1) Report > Merging [#4426](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4426?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/8d26793249e32cb20ae522815b0d14c713378be4?src=pr&el=desc) will **decrease** coverage by `3.83%`. > The diff coverage is `n/a`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4426?src=pr&el=h1) Report > Merging [#4426](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4426?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/8d26793249e32cb20ae522815b0d14c713378be4?src=pr&el=desc) will **decrease** coverage by `3.83%`. > The diff coverage is `n/a`.
I just encountered this when I in my own source-code dump into a directory and that directory is open in a File Explorer window. Perhaps that helps someone on Rubber Duck track down this error.
I just encountered this in my own source-code when it dumps into a directory and that directory is open in a File Explorer window. Perhaps that helps someone on Rubber Duck track down this error.
> More details on my circumstance - The offending File Explorer has the directory open when I programmatically delete it. The delete succeeds and bumps the File Explorer window out of the (now deleted) folder, but a retry is still required of the user to complete the operation. Presumably a test of the folder being open would avoid the problem.
> More details on my circumstance - The offending File Explorer has the directory open when I programmatically delete it. The delete succeeds and bumps the File Explorer window out of the (now deleted) folder, but a retry is still required of the user to complete the operation. Presumably a test of the folder being open, or perhaps just a slight delay, would avoid the problem.
The visualizer fails on nodes matching an empty string.
To get some output, you have to make the moduleAttributes and moduleDeclarations in the module rule optional and change the rules themselves from * to +.
Btw, I do not really like the visualization.
I very much prefer the rectengular lines in the Eclipse add-in.
@M.Doerner double checking - I don't dispose any VBComponent provided by the IProjectRepository, correct?
I know that it shouldn't be done for the collections like IVBProjects and IVBComponents but want to be sure if the same rule applies to individual objects.
as mentioned yesterday, i only have 3 GC'd SCW, all coming from events. After sleeping on it, I made decision that the ComponentEventArgs should be using QMN and pass it around. That way there is no SCW being marshaled across events.
Welp, that's interesting. After having removed all the GC'd SCW from the COM safe, I still have a hung Access instance. But - when I compare the snapshot & trace against the one where I open the Access form in design view rather than form view, we leak almost 600 SCWs but still get a clean shutdown with Access.
Whereas opening an Access form in the Form view & parsing will get me a clean COM Safe with no GC'd objects but a hung instance.
Well, maybe not 100% clean - there are still 3 more objects that do not have a balancing Removed entry, but those are the VBE, AddIn and IHostApplication - they may be removed too late when it ends the tracing.
ThunderFrame gave us a whole lot of good time, tons of inspection ideas, ThunderCode™ proofing, the unforgettable spinning ducks, the face-of-the-project ducky, and so much more. Last night he emailed me to say he was up against an aggressive stage IV melanoma and heading to the hospital. Let our hearts be with him and his family.
My current code takes a set of caller information ("calldataFile" or "CD_") and allocates it back to the specific source that it came from into a different file ("Internal File" or "WT_").
The code takes between 72-75 seconds to run for the specific data set I'm testing. Considering that is a...
VBA Rubberducking
VBA Rubberducking