以未定义的元素在JSON中循环(loop in JSON with undefined elements)

 不，不是所有类型都有默认成员。 
 
 任何类模块都可以拥有一个默认成员，通过指定一个特殊的成员属性 （您必须手动导出和编辑代码文件来执行此操作，VBE不会公开任何此功能）： 
 
Attribute {member name}.VB_UserMemId = 0
 
 只有一个成员被允许成为类型的默认成员。 
 
 
 你正在发现默认会员的尴尬，以及为什么他们应该避免。 
 
 VBA做了很多事情来“让我们的生活更轻松”（例如隐式类型转换），而默认成员就是其中之一。 
 
 
 
 集合可以存储非静态引用 
 
 
 我不知道什么是“静态引用”，但是当你在一个Collection存储一个对象引用时，你并不是存储该对象的副本，而是存储它的引用 。 
 
 
 
 Cells()和其他对象没有默认属性，如.value 。 
 
 
 Global.Cells是一个返回Range对象引用的参数化属性获取器; Range.Cells也是一个返回Range对象的getter; Excel对象模型中没有Cell类。 Range的默认成员是一个隐藏的[_Default]成员，似乎可以解析为其Value 。 但是当你这样做时： 
 
Dim c As Collection
Set c = New Collection
c.Add ActiveSheet.Cells(1, 1)
 
 然后你添加.Cells(1, 1)返回的Range引用，然后这个： 
 
Debug.Print c.Item(1)
 
 将输出该Range对象的值。 然而这个： 
 
Debug.Print TypeName(c.Item(1))
 
 将输出Range 。 
 
 混乱？ 是。 这就是为什么你应该总是指定Option Explicit ，尽可能使用明确类型声明的变量，避免隐式类型转换......并避免使用默认成员。 
 
 通过编写完全按照其行为表示的代码，您可以避免大量的VBA陷阱，而当您最终想要学习一些VB.NET或C＃时，您绝对不会遗漏类型安全性和显式性。 

No, not all types have a default member.
 
Any class module can have a default member, by specifying a special member attribute (you'd have to export and edit the code file manually to do this, the VBE doesn't expose any functionality for this):
 
Attribute {member name}.VB_UserMemId = 0
 
Only one member is allowed to be a type's default member.
 
 
You're discovering the nastiness of default members and why they should be avoided.
 
VBA does a lot of things to "make our lives easier" (e.g. implicit type conversions), and default members is one of these things.
 
 
 
Collections can store non-static references
 
 
I don't know what a "static reference" is, but when you store an object reference in a Collection, you're not storing a copy of the object but a reference to it.
 
 
 
Cells() and other objects do not have default properties such as .value.
 
 
Global.Cells is a parameterized property getter that returns a Range object reference; Range.Cells is also a getter that returns a Range object; there is no Cell class in the Excel object model. The default member of a Range is a hidden [_Default] member that appears to resolve to its Value. But then when you do this:
 
Dim c As Collection
Set c = New Collection
c.Add ActiveSheet.Cells(1, 1)
 
Then you're adding the Range reference that .Cells(1, 1) returns, and then this:
 
Debug.Print c.Item(1)
 
Will output that Range object's value. Yet this:
 
Debug.Print TypeName(c.Item(1))
 
Will output Range.
 
Confusing? Yes. That's why you should always have Option Explicit specified, work with variables declared with an explicit type as much as possible, avoid implicit type conversions, ...and avoid using default members.
 
By writing code that reads exactly as it should behave, you avoid a number of VBA traps, and when you eventually want to learn some VB.NET or C# you won't be lost at all about type safety and explicitness.