Rubberduck: COM collector: Built-in declarations should probably not all be marked as "GlobalNamespace"

Created on 13 May 2016  路  10Comments  路  Source: rubberduck-vba/Rubberduck

Right now this does not resolve at all because Range is resolved to a class module because all collected class modules in type libraries are marked as default instance variables / in the global namespace.

Public Sub Test()
  a = Range("A1")
End Sub

Do we have that information somewhere in the type libraries?

bug parse-tree-processing

Most helpful comment

Yes, I agree. Sorry if I wasn't clear. What I meant was that ClassModuleDeclaration has constructor parameter called IsGlobalClassModule that overrides what is in the attributes. The COM collector currently sets that parameter to true, so it might not work if you're testing the new COM collector if you don't remove this parameter.

All 10 comments

Not sure where that GlobalNamespace is coming from; I'm looking at TYPEATTR.wTypeFlags, and assuming TYPEFLAG_FPREDCLID means there's a PredeclaredId attribute:

            var typeAttributes = (TYPEATTR)Marshal.PtrToStructure(typeAttributesPointer, typeof(TYPEATTR));

            var attributes = new Attributes();
            if (typeAttributes.wTypeFlags.HasFlag(TYPEFLAGS.TYPEFLAG_FPREDECLID))
            {
                attributes.AddPredeclaredIdTypeAttribute();
            }

Ah, my bad I actually broke that part then.

Here's the description of default instance variables: 5.2.4.1.2 Default Instance Variables Static Semantics.

From what I understand if VB_GlobalNamespace is not set to true you shouldn't be able to access the members of the class in a different project, because they can't be used in simple name expressions, e.g. you can't simply type in Range("A1")

According to TYPEFLAGS enumeration under "Remarks" this might be the case if TYPEFLAG_FAPPOBJECT is set.

What about VB_Exposed though? I'm not sure which flag specifies that. There's one that hides the type from the object browser. Or should we simply assume that all types are accessible?

Oh wow, nice catch there - looks like TYPEFLAG_FAPPOBJECT is indeed what I need to look at!

Let's assume all types are accessible... until it creates problems :) or would that be TYPEFLAG_FHIDDEN?

OK, just a heads up, the current ClassModuleDeclaration has a parameter isGlobalClassModule which should probably deleted if we only use attributes (it's only used because of the COM collector).

Bah, I find they make a convenient getter that checks for a specific attribute.... no?

Yes, I agree. Sorry if I wasn't clear. What I meant was that ClassModuleDeclaration has constructor parameter called IsGlobalClassModule that overrides what is in the attributes. The COM collector currently sets that parameter to true, so it might not work if you're testing the new COM collector if you don't remove this parameter.

I remember working on this a little while ago, but not sure if it ended up merged or overwritten. @autoboosh is this still an issue or it's fixed?

Just had a look at the com collector and it doesn't look like it doesn't add the global namespace attribute, so yes I think this is still an open issue.

Edit: Sorry for the double negative. What I meant to say was that this isn't a non-issue.

Edit2: It's still an issue. Please have a look at it if you get a chance :)

Deemed fixed. @comintern can you confirm?

Confirmed.

                if (module.IsAppObject)
                {
                    attributes.AddGlobalClassAttribute();
                }
Was this page helpful?
0 / 5 - 0 ratings

Related issues

ChrisBrackett picture ChrisBrackett  路  3Comments

SteGriff picture SteGriff  路  3Comments

Gener4tor picture Gener4tor  路  3Comments

retailcoder picture retailcoder  路  3Comments

retailcoder picture retailcoder  路  3Comments