Object Neighborhoods
The purpose of Object Neighborhoods is to make it easier for objects to communicate with each other. Objects within a neighborhood can talk to other objects within the neighborhood by their simple object name without needing to worry about where those objects are located.
Object Neighborhoods simplify the management of visual objects within views. In a view, visual controls are often nested inside containers for appearance purposes only. As you design an application, you may decide that it looks better to place several objects within dbGroups, and then place those groups within a dbContainer3d. The Studio makes it very easy to make these kinds of changes. However, every time you move these objects around and put them in different containers, you change the way those objects are referenced from other objects within the view. This creates the need to generate complex object reference statements, which may require code changes every time you move objects around. This results in code that looks like this:
Get SortOrder of (oSortOrder(oSortParamsGroup(oSetUpContainer(;
oTabPageReport(oTabDialog))))) to iOrder
If you decide to move your oSortOrder object somewhere else in the view, you need to start all over.
With neighborhoods, all objects in the view are registered with the view, and all objects within the view are visible to all other objects within the view. The same object placed anywhere within the view is now coded as:
Get SortOrder of oSortOrder to iOrder
Object neighborhoods "flatten" the object structure of visual controls, making it possible for all visible controls to see each other. Objects will still properly encapsulate (hide) non-visual and class-based objects that are clearly not meant to be public. This allows easy access to the objects you want while still writing properly encapsulated applications.
Public Neighborhoods
Views (dbView, View, ReportView, etc.) and panels (Panel, ModalPanel, dbModal, etc.) are defined as public neighborhoods. All objects within a neighborhood can communicate directly with any other object within the neighborhood by name. In TabDialog views, where each tab page (dbTabView) is treated as a separate view, each tab page is defined as a neighborhood.
If you use neighborhoods, ensure that each object within the neighborhood has a unique name. While this restriction only applies if you plan on sending messages to an object that has a duplicate name, it is good practice to uniquely name all objects within a neighborhood.
Note that object neighborhoods are used primarily to provide simpler access to visual objects. Non-visual objects, such as Web Objects, do not use object neighborhoods and, when properly coded, do not need to use neighborhoods.
You can determine how any object participates in neighborhood settings via the peNeighborhood property.