Defines whether objects in other Modules can access the object. It can be specified either at the Module or object level.
Setting a value at the Module level changes the default value for all objects in the Module.
||Any object in any module can access a public object.
||Only objects in the same module (and its child modules) can access private objects.
||Only objects that have a common root module (child of the one named 'Root Module') can access internal objects
The default value for a given object is inherited from its parent Module object.
One goal, when designing a Module object, is to define how it is going to be used (i.e. how other modules can interact with the one that is being defined). Some Module objects may be accessed elsewhere in the Knowledge Base and some may not.
By setting the appropriate value of the Object visibility property a developer can control how each object can be accessed outside its Module, that is, design the Module interface.
|-- |-- ProcA
|-- |-- ModuleA1
|-- | |-- ProcA1 //Public
|-- | |-- ModuleA11
|-- | |-- ProcA11_Internal //Internal
|-- | |-- ProcA11_Private // Private
|-- |-- ModuleA2
|-- |-- ProcA2
In this example
- ProcRoot can call ProcA1. It cannot call ProcA11_Internal and ProcA11_Private
- ProcA, ProcA1 and ProcA2 can call ProcA11_Internal. They cannot call ProcA11_Private
- ProcA11_Internal can call ProcA11_Private
- When packaging ModuleA1, only ProcA1 is part of its interface.
How to apply changes#
When an object's visibility is changed, all the objects that have references to it are automatically specified by the next Build operation. They may not need to be generated.
This property is available as of GeneXus Tilo Beta 1.
The value 'Internal' is available as of GeneXus 15 Upgrade 3
Modules vs. Folders
Modules - Dynamic calls