[rubberduck-vba/Rubberduck]MDoerner pushed commit f91d542a to next: Fixed failing tests by allowing line numbers and line labels after line continuations and consuming the trailing whitespace after a line continuation in
@Comintern What's sad is when you google a question/topic that has you perplexed, only to find the resolution in RD chat or on SO, and find that a wiser you is the author. But at least Google is somewhat private. Worse still is when you ask a question in RD chat, and somebody else responds with a permalink of a wiser you answering that exact question.
I'm curious to see my line add to line remove count afterward. It should be steeply negative.
@this Not yet. I'm afraid if I look at it too much I'll be overcome with temptation to start poking at the Immediate Window interface. That's a one way ticket down the rabbit hole.
Would it be dangerous to do lazy evaluation of type names? If I wait to resolve the AsTypeNames until the entire library is processed, it should be a lot more efficient. The only caveat is that they wouldn't necessarily be valid until the entire typelib was processed.
> VersionStamper is included for legacy application support, we do not recommend it for new development.
Learn more about VersionStamper
Buy Desaware's VersionStamper as Part of the COM Universal bundle for $649 or Buy COM AND .NET Universal packages for $995 .
That struck me as hilariously ironic. "It's old but we'll charge you a lot of money for it"
That said, that was interesting read but largely inapplicable because we aren't using any external program to register our COM programs (and IMHO, we shouldn't be).
VersionStamper would have been of interest but that line above stopped me.
@this Yes and no. It's currently grabbing names for things as strings if they haven't been processed as full object yet. One case would be something like this:
if (!IsEnumMember || !ComProject.KnownEnumerations.TryGetValue(_enumGuid, out ComEnumeration enumType))
{
return;
}
var member = enumType.Members.FirstOrDefault(m => m.Value == (int)DefaultValue);
DefaultAsEnum = member != null ? member.Name : string.Empty;
That's in the function parameter resolution. I think it currently hits all on all of them that it should (or at least most), but if they process out of order, you wind up with things like "As Integer" instead of "As vbColor".
Both are perfectly valid declarations from the standpoint that VBA "sees" vbColor as an Integer internally, but it isn't as shiny in the status bar that way.
@MathieuGuindon The type annotation pass is getting Declarations. so the COM member names have already been cast in stone as strings at that point.
I still want to replace the Declaration objects with these at some point. That would pretty much end the scope resolution problems from string matching.
We could leverage the crap out of @WaynePhillipsEA's internal typeinfo API and build an "scope tree'.
So... if your identier reference is inside a UserDefinedProperty, it would walk up the tree checking to see if it was in each parent's Members collection.
Yep. And the caching problems. And the performance issues for huge projects due to the reference finder. And a bunch of other problems like over-reliance on identifier names.
and 9 flattened declaration lists were given to the humans, who above all craved for power. but they were all fooled, for another tool was forged in the blazing hells - a tree to rule them all.
at first there was a shitty regex-based kind-of-tokenizer. then with v1.2 Antlr came along, and my shitty painter-algorithm resolver survived until ~v1.3 IIRC. then it awgaya rewrote the heck out of it, Max took it over, and so far that's surviving throughout 2.x
so... 4th?
yet, Declaration and IdentifierReference have been around all along
I am using the ITypeInfo interface to obtain information about COM objects and their members (in order to build some kind of reflection API). Reading types and members (and their parameters) works fine, but I don´t know how to access a parameter´s default value. This is what I have...
...
PARAM...
@Comintern it used to be that double-quotes helped to bring back exact matches. iirc, a + sign used to force that term to be present, but it seems inconsistent these days
@ThunderFrame BTW, a co-worker got the new Office toolbar in her Windows updates last night. It only installed in Access and Word, but for some reason didn't in Excel. It made Access completely unusable.
@MathieuGuindon We link to all 3 articles in that series (the other 2 of which aren'on yanaware, iirc), from the wiki. - brakmic.com/iunknown/tag/com - but I see now the link is broken
@Comintern I looked at the DnD content a while back, I could get info from the Project, iirc, but I wasn't using OleView as the drop target. I made my own. iirc - it was just a list of files. What you've found is way more interesting
@Comintern There should be an inspection for don't use RefEdit control - it's a corruptor of projects/state
@MathieuGuindon Rubberduck wiki now has the most complete set of links to the Sean Baxter articles - and I made them all archive.org links, so hopefully they won't die.
Holy crap, that ran so much faster I didn't think it did anything.
2018-07-19 00:21:06.5653;TRACE-2.2.6774.517;Rubberduck.Parsing.VBA.COMReferenceSynchronizerBase;Loading referenced type 'ADOR'.;
2018-07-19 00:21:06.5756;TRACE-2.2.6774.517;Rubberduck.Parsing.VBA.COMReferenceSynchronizerBase;Loading referenced type 'ADODB'.;
2018-07-19 00:21:06.6534;TRACE-2.2.6774.517;Rubberduck.Parsing.VBA.COMReferenceSynchronizerBase;Loading referenced type 'Scripting'.;
2018-07-19 00:21:06.6534;TRACE-2.2.6774.517;Rubberduck.Parsing.VBA.COMReferenceSynchronizerBase;Loading referenced type 'VBScript_RegExp_55'.;
All the reference libraries that we serialize in .31 seconds.
@this and besides, I donated $100 to them last year, so they should be good for a while. I just wish there was a search capability for a particular timeframe, not just "give me this specific URL for whatever dates you have." I can't imagine that temporal search would take much resources....
> It occurred to me that a referencing project will only ever see the public members of a referenced project, regardless of whether that project is protected, or has its protection removed during a VBE session.
If a project, say `DBUtils` is referenced, but protected, then RD currently skips it entirely, but it should perhaps be using the TypeLib API to get the public declarations, and if the project is subsequently unprotected, then RD should do a full parse and resolve on the next parse, of
@Comintern ^ I lost my work on submitting that comment, and despite a second rewrite, I'm still not certain that I'm being clear. Does it make sense to you?
@Comintern @MathieuGuindon The idea of a scope tree is really not new. I mentioned at least three times already in this chat that that is the standard approach to build symbol tables, which is also explained in the corresponding book by the Antlr guy. We simply do not do it that way.
I would also like to add that resolving probably be slower not faster using the scope tree alone. Name collisions are not too common. So first doing a dictionary lookup for the name is rather efficient. If there are multiple matches, you can still fall back to a scope analysis.
Moreover, our Declarations are already kind of a scope tree, just without the resolve method. They just need a cleanup, for which there is already an issue. (Nothing should ever use the base class.)
We also cannot get rid of the QMNs. We need these as a proxy for the components. Remember that we must not distribute COM object everywhere because they require proper cleanup. Otherwise, our crash on exit will just become worse again.
> I think this issue is kind of intertwined with #3041.
When we implement a setting to choose projects that should only be loaded from the typelib (as built-in declarations), we could add an option to add all protected projects to the list automatically. Then, temporarily unopotecting will not change how RD treats the project. Moreover, you can opt out of the automatic addition and manually revert the status.
> I do not see what you are getting at regarding parsing multiple times. We ever only parse a project/read in a referenced library once and then resolve all references from all referencing projects based on all the declarations we have and the scoping rules.
We actually add some caching so that we do not reload referenced libraries or parse modules unnecessarily.
I wanted to implement Dijkstra's Algorithm in an Excel VBA Add-In and built it to be used as follows:
Define a list of paths with distances between points. This list needs to contain 3 headings that are used as flags to pick up where the list is. The 3 headings are !dijk:dat:from, !dijk:dat:to ...
> @MDoerner - I'm unsure if you missed my point. A project that refers to another project should only ever know about the public decorations, parameter and return types of the referenced Project, and despite my first comment, that doesn't change, regardless of whether the referenced project is or isn't protected, or was protected and became unprotected. But a referenced project that opens as protected, but is subsequently unprotected, will itself subsequently need to have all of its public *
> I still do not get your point. The resolver adheres to the scoping rules, which means that a reference to an object in a referenced project/library only ever resolves to a public object. We do not specifically present a set of declarations from a referenced project to the referencing one. We always use all declarations and apply the scoping rules, which means that private objects in a referenced project are not visible to the referencing project.
@M.Doerner ok, I understand. I was forgetting that RD adhered to the scoping rules of the referenced project. The protected nature of the referenced project is moot in that regard, other than this will be the first time that we've been able to parse members of a protected project.
@PeterMTaylor You need to check the Rubberduck.Interaction, Rubberduck.Refactoring and Rubberduck.Resources and ensure that each has the RubberduckCodeAnalysis project checked off as a dependency. You could also copy the changes to the .sln file from Max's PR.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=h1) Report > Merging [#4127](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/9d5f49a5e60e66eed77236da94402087a9dd86c0?src=pr&el=desc) will **increase** coverage by `0.55%`. > The diff coverage is `92.74%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=h1) Report > Merging [#4127](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/9d5f49a5e60e66eed77236da94402087a9dd86c0?src=pr&el=desc) will **increase** coverage by `0.58%`. > The diff coverage is `92.81%`.
> I was thinking - the com collector stuff are in the Rubberduck.Parsing. It deals a lot with COM particulars, involving pointer and unmanaged types management. Would it be better to separate that into its own project, so that there is no direct dependency on COM stuff from within the Rubberduck.Parsing project? Thoughts?
helo,i am a bit green in vba . I want to create a code that allows me to copy and paste my scoreboard plus resize the rows as many times as possible. but only pasting one copy for each run.
@Duga If we do move the COM stuff, let's wait until it's been in "production" for a while - rearranging the files blows away the history that is easily accessible via VS git integration.
@Comintern no rush, really. TBH, I'm not sure if there's any gain in doing so. It was a good thing for the safe com wrappers now that we have the abstraction in the VBEEditor project, which allowed us to remove all references to PIAs in all other projects so that trying to use a RCW type directly will light up red. In com collector's case, though, we're mainly using stuff from System.InteropServices namespace.
Yeah. Unlike the RCWs, we usually don't need to hold them beyond the scope of the method that bought them into existence, which simplifies the management providing that we plugged all leaks.
The Variant thing might prompt me to address #4172, although I'm not entirely sure that the COM collector needs the full fidelity there, given the rules for what you can define as a constant.
I was also looking at #4050 and realized that was why we're getting build warnings about our public interface. COM wants then to be Variant instead of Object.
I was mainly thinking of the managed side. Although if they're marshalling as VT_ERROR, would the overload without the optional parameter ever be called from unmanaged code?
Not directly, but my understanding was always that the CLR builds 2 versions of the function anyway. Kind of like you "manually" overloaded it instead of adding an optional parameter.
When I transferred ownership of the repository from my account over to the 'rubberduck-vba' GitHub organization, it was to make it easier to collaborate and work as a team. Throughout the years, core contributors and domain experts have turned my i
I wanted to implement Dijkstra's Algorithm in an Excel VBA Add-In and built it to be used as follows:
Define a list of paths with distances between points. This list needs to contain 3 headings that are used as flags to pick up where the list is. The 3 headings are !dijk:dat:from, !dijk:dat:to ...
helo,i am a bit green in vba . I want to create a code that allows me to copy and paste my scoreboard plus resize the rows as many times as possible. but only pasting one copy for each run.
VBA Rubberducking
VBA Rubberducking