Controls
Controls are named by using a three letter abbreviation of the control’s type, appended by an underscore, and then appended by a description of this control’s function. Databound controls should use the dictionary column name for this descriptive portion. Multi-column controls (i.e. Edittables) should use the primary dictionary column name or a general description that applies to the whole control.
| Control Types | Name Prefix | Comments |
|---|---|---|
| EDITBOX | EDB_ | |
| EDITFIELD (EDITLINE) | EDL_ | |
| EDITTABLE | EDT_ | |
| CHECKBOX | CHB_ | |
| COMBOBOX | COB_ | |
| LISTBOX | LIB_ | |
| PUSHBUTTON | PUB_ | |
| RADIOBUTTON | Radio button names are defined by the text that appears on the form. Therefore, no special rules can apply. | |
| RADIOGROUP | RAG_ | |
| HSCROLLBAR | HSB_ | |
| VSCROLLBAR | VSB_ | |
| ICON | ICO_ | |
| MENU | Menus are automatically named by OpenInsight’s menu generator. Even though these can be overwritten, it is usually easier to leave them alone unless their name lengths become too long. Menu names (or any control) that exceed approximately 50 characters in length might not execute events properly. | |
| BITMAP | BMP_ | |
| GROUPBOX | GRB_ | |
| STATIC | STA_ | |
| PUSHBMP | PUB_ | PUSHBMP’s are PUSHBUTTON’s with a bitmap overlay. |
| RADIOBMP | RAG_ | RADIOBMP’s are RADIOGROUP’s with a bitmap overlay. They cannot be created from the Form Designer but have to be created on-the-fly using Basic+. |
| CHECKBMP | CHB_ | CHECKBMP’s are CHECKBOX’s with a bitmap overlay. |
| RTFBOX | RTB_ | Notes that RTFBOX’s are EDITBOX’s with the Rich Text style set. |
| OLECONTROL | OLE_ | Alternatively, use an appropriate abbreviation for the ActiveX control that is being loaded into the OLE control itself. For instance, the SRP OLE EditTable could also be EDT_, although some distinction would need to be made if an OI and OLE EditTable were used to represent the same data. |
| HSPLITBAR | HSP_ | |
| VSPLITBAR | VSP_ | |
| TABCONTROL | TAB_ |
Windows
Windows can have a great variety of styles so no attempt will be used to name them accordingly. However, the general functions of windows can be grouped into a few categories and these categories will form the basis for the three letter abbreviation. Like controls, this abbreviation will be appended by an underscore, and then appended by a description of this window’s function. Databound windows should use the table name for this descriptive portion.
| Window Categories | Name Prefix | Comments |
|---|---|---|
| General Databound | DBW_ | |
| MDI Frame | FRW_ | |
| MDI Child | DBW_ | MDI Child windows are created as General Databound windows and can even be executed as General Databound windows. They only become MDI Child windows when launched within an MDI Frame. Therefore, for simplicity no distinction in naming will be used. |
| General Non-databound | NDW_ | |
| Toolbar | TBW_ | These are General Non-databound windows that are primarily used for launching other windows via PUSHBUTTON and MENU controls. |
Stored Procedures
Stored Procedures that handle business rules will almost always be name in a meaningful way. Some Stored Procedures, however, perform common but special purposes in virtually all applications and therefore will have their own naming standards.
| Stored Procedure Type | Name Prefix | Comments |
|---|---|---|
| General | See comments | Stored procedures should be named using full (verbose) words, each separated by an underscore. Since OpenInsight forces all stored procedure Key IDs to be saved in all caps, using the underscore will make it easier to identify a stored procedure name by its constituent parts. |
| Commuter Module | Window_EVENTS | This is the pattern that Revelation has officially adopted to correspond with their Call Commuter Module QuickEvent. It is also the pattern that SRP FrameWorks expects to find in order to avoid using Event Script and QuickEvent handlers. |
| Services Module | Category_SERVICES | This is a commuter for the SRP FrameWorks service oriented architecture. Category should be named based on what unifies all of the service requests contained in the service module. This might be the name of a window, table, or general module within the application (e.g., SECURITY_SERVICES.) |
| Table Actions | Table_ACTIONS | This is a commuter module for all MFS activity for a given table. Since MFS code is cached, it is easier to maintain an MFS shell that calls a separate stored procedure to handle the logic. |
| List-type Report | RPT_ReportName | List-type reports can be completely written in Basic+ (OIPI) or a combination of Basic+ and reporting tool (e.g. Report Builder+ or S/List). |
| Form-type Report | FORM_FormName | Form-type reports are paper representations of a single record, like a purchase order, invoice, or quote. |
| MFS | Table_MFS | SRP FrameWorks already provides BASE_MFS, which is a shell to call the appropriate Table_ACTIONS routine. If a unique MFS is needed then Table_MFS would be the recommended naming standard. |
| Promoted Event Handler | AppName_EventType_Window_OIWIN | This naming pattern is based on the actual naming standards required for the SYSREPOSEVENTEXES table in order for the event to be recognized by OpenInsight. |
| Promoted Event Commuter | Promoted_EventType_Event | All Promoted Event Handlers call a general function call Promoted_Events, which in turn dynamically calls each Promoted Event Commuter (if it exists.) |
| INET Routines | INET_RoutineName | This pattern is required by OpenInsight for all OECGI procedures. |
| Remote Engine Requests | RE_RoutineName |
Message, Popups, and Reports
Names for supporting application components should follow rules of common sense so that they are inherently meaningful. There is no reason to label them in any generic way (e.g. MSG_CONTINUE) since the context of the code will almost always make it clear what kind of component is being used.
