Overview of subsequently added object properties that are only accessible via the "Properties" collection. (2 Viewers)

[The_Doc_Man]

One of the things we need to remember - and this frequently IS forgotten - is that the Component Object Model is actually a facade. Think about class modules that have Property_Get, Property_Let, and Property_Set methods to extract the "values" associated with certain properties of a class object. Just about EVERYTHING you see using COM methodology for property lists is a table dynamically filled by a sequence of Property_Get methods. Although MSFT certainly CAN - and probably does - create convenient data structures to hold all this information, it is being translated for you into a tabular presentation that we call the "property sheet". It is closely analogous to datasheet view of a record that contains numeric and text fields. But Access, not being Open Source, isn't showing you everything as it really is. It is "prettying up" the things it shows you. And actually, that is true for the internals of Excel, PowerPoint, and Word - though given the way that Word handles paragraphs and individual words - What You See Is NOWHERE CLOSE To What You Actually Have.

See also

Component Object Model (COM) - Win32 apps

The Component Object Model is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents) and ActiveX technologies.

learn.microsoft.com

MajP's comments on how properties appear and disappear is simply a description of what the COM "black box" presents to you under various and sundry circumstances. (Nice work, though, @MajP, given the craziness of the COM environment.) The reason that unbound controls don't have certain properties is simply because the behind-the-scenes COM interface chooses to not present a property it knows is currently meaningless.

 

[MajP]

The reason that unbound controls don't have certain properties is simply because the behind-the-scenes COM interface chooses to not present a property it knows is currently meaningless.

I think I showed that is not very exact with lots of exception.
There are properties added to the properties collection that have no meaning (scale and precision on a text field)
There are properties that have meaning but are not visible from the GUI (the display control on a calculated field)

 

[The_Doc_Man]

It all boils down to what COM (i.e. MSFT in their infinite wisdom) decides to show us.