NVZN 11 - PowerForce™


To outline the standards and naming conventions used in the development of applications in the NVZN environment.  This ensures consistency amongst programmers leading to easier maintenance and ongoing development.  It also ensures consistency within the user interface making the application simpler for the end user to learn and use.  Rapid development also relies on the use of promoted events.  The promoted events logic relies on specific naming conventions in order for them to function.






Top of Page

Windows and Commuter Modules

The primary naming convention for windows and their corresponding commuter modules is that the window and the commuter module must have the exact same name.  This ensures that the promoted events functionality is executed.  With the promoted events functionality operating correctly, there should be no need to place any code/logic within a form itself.  The form designer need only be used to ‘draw’ the window and then all relevant logic is coded for within the commuter module.  In this way, ongoing maintenance of any window is simple because there is only one place to go to find what you are looking for.  There is no hunting through scripts or quickevents to identify what is being called and what parameters are being passed.  Everything automatically ends up in the commuter module.

As well as the convention for ensuring the window and commuter module have the same name, a standard for the creation of the actual name has been defined.
A window name has the following format:


Where ‘(module)’ is replaced by a specific character indicating the module that the window relates to and ‘nnn’ is a three digit number simply indicating the next window in sequence.  Therefore an actual window name would appear as:

NVU_001 where ‘U’ represents ‘Utilities’ and ‘001’ indicates this was the first utility window to be developed using these conventions.

The corresponding commuter modules would then have the header in the format:

Function NV(module)_nnn(CtrlEntId, CtrlClassId, PassedEvent, p1, p2, p3, p4, p5, p6)
The module characters are currently defined as such:






Any windows that have a direct influence on the billing of customers



Windows that allow editing or displaying of customer/client data



Windows that allow editing or displaying of employee data



Windows that have a direct relationship with a file.  Their only purpose is to directly edit/maintain data within file attributes.  Eg reference files



These are windows that enhance the interface for the user but are generic in nature.  They are not necessarily related to any particular module and can be used in multiple instances where like functionality is required.  Often they are designed without borders so they can be embedded into a shortcutbar within another window.  This enhances the functionality of the parent window without rewriting any supporting logic.  Eg NVG_Month provides the ability to display a calendar showing public holidays etc on any window.  If not embedded, the calendar can still function the same by having the ‘OLE’ event within the commuter module of the parent window, call NVG_Month and just passing across the same parameters as it has received.  One line of code within the parents’ commuter and all of NVG_Month’s functionality is available.



Any windows that have a direct influence on the paying of employees



Any windows that have a direct relationship with rostering.  This may be preparing or displaying rosters in any format.



Timesheet windows differ from Rostering windows in that they are generally for entering tabular data post event rather than preparing work in advance or viewing various combinations at once.  Timesheet data is usually like data that is repeated with only minor differences between entries, eg different dates.



Utilities are windows that can be categorized in one of two ways.  Either they are designed for system maintenance or they are for users to perform specific functions that may be generic in content but are specific in their purpose.  ‘Utilities’ differ from ‘GUI’ in that GUI windows generally serve to enhance the user interface/experience whilst utilities have a specific function to perform.
Eg. NVG_Month vs NVU_003
NVG_Month provides the user with a calendar for convenience.  Whilst it has some further functionality the user can make use of, the lack of the calendar would not adversely affect the user.
NVU_003 on the other hand provides the user with the ability to transfer data from a large list to a smaller more personalized list to improve their overall system use.  The content of the lists may be generic, but the purpose or function is always the same, to create a sublist of items from a larger system list.

Top of Page

Standalone Functions / Modules

These are functions or procedures that perform a specific purpose and have no direct relationship to a window.  As they have no direct relationship to a window there is no need for the ‘module’ character.
These function names have the format:
NV_function_name(p1, p2)

The number, name and type of parameters within the brackets will be dependant upon the function’s requirements.  The ‘NV_’ is the primary naming convention for functions.  There are instances however where the ‘NV_’ does not apply.  Functions that either write or retrieve data from file are likely to be application specific rather than environment (NVZN) specific and as such, are not prefixed with NV.
Any function retrieving data from file is named:

Get_filename(key, directive, datatoreturn, record)

Any function writing to file is named:

Set_filename(record, key)

 The Get and Set_filename routines will in turn call the corresponding NVZN function:

nv_GET_FROM_FILE(Record, fileUnit, Key, P4)
nv_SET_TO_FILE(record, FileUnit, Key, Params, IgnoreUpdateLog)

Top of Page

GUI Functions / Procedures

For consistency across the application, functions have been written to assist in initializing/defining OLE controls.  These functions serve a dual purpose.  Firstly, they make it simpler for the programmer to set multiple properties of certain controls without the need for an in depth knowledge of the control itself.  Secondly, using the setup functions ensures that like controls behave in the same manner throughout the application, so the user only need learn how to use the control once and all other occurrences will function virtually identically.  This still leaves room for customization where appropriate but the underlying appearance and behavior will be consistent.  As these functions are a product of the environment (NVZN) and can be used across different applications built on top of NVZN, they all have the NV_ prefix.  They are in fact all in the format:

Initialisation Functions

Function Name



CtrlEntId, IsButton, Caption, ToolTip, Icon, Style


CtrlEntId, DateRange, ShowToday, ShowPublicHols, NoMonths, WeekNumbers, MonthsToScroll, theme


CtrlEntId, TitleList, ColWidths, SelColWidths, RowNumbers


CtrlEntId, Image, Layout


CtrlEntId, Theme, Animation, PopupSize, Showtime, AllowMove


CtrlEntId, ColumnList, ColWidths, ColTypes, Visibility, ColFormats


CtrlEntId, Captions, Images, Height, UseXPTheme


CtrlEntId, Background


CtrlEntId, ColumnList, StyleType, ValueList

Top of Page

Edittable Management Functions

Edittables can vary from being very basic in design and use, right through to complex animals in their own right.  Each and every cell within an edittable can have its own characteristics to alter the way in which it interfaces with the user.  In a majority of cases however, each cell within a column usually behaves the same as the cell above.  To manage the characteristics of a column within an edittable, a further function has been created which will generally be called after the call to nv_setup_ole_edittable.


Style Type



Add a checkbox to the cell.  This may be alongside or instead of text


Add dropdowns containing a list of data the user can select from


Make the contents of the cell flash different colours


Hide the entire column, so that it is invisible to the user


Add an option button to the edge of the cell which can be used to fire off further events. A dropdown arrow is an example of this.


A cell/column can have different levels of protection.  Use this style to manage the editing capability of the user.


Convert a cell to a button which can be clicked


Ensure that all data entered will always appear in upper case


Top of Page

REPOS version numbering

nv_version$$ = "[ver: c167]"
IF CtrlEntId[1,5] _eqc "ver$$" THEN
    RETURN nv_version$$

What needs to happen in that the repos other than baseline introduce a letter post the date to indicate which repos.

e.g.[ver: c167e] - specific repos centric code will assist in not overwriting customised source.

Top of Page

Custom Code (Client Specific)

  • In an attempt to get away from naming subroutines with 32 char names,
    "CU" - custom
    Customer_id (max 6 chars)
    "NN" - counter (exceed 99, go into AA), and then it should probably really be a module.

$INSERT custom_code_equates - lists the custom clients

Creating the deployment(s) - we'll need to make customer specific deployments - as I don't want the REPOS of everyone to be polluted with other client nonsense.

We'll have to manually keep track of this at this stage, however, once git is integrated into the world, we'll use it to manage repository patches.

Top of Page

nv_error management

The intent of this enhancement is to deliver a framework for 'zero-support', where all error messaging is managed through software.

The main data is of course the errror message, and we'll adopt a format similar to reverror.dat (until an alternate path is adopted).

The current format of the file is (as below). Our keys will be 'XXX', which allows for over 17,576 unique message ids before we need to grab for something new.


E10: %1%, line %2%. Variable has not been assigned a value.
E12: %1%, line %2%. Table has not been opened.

Top of Page



Top of Page



Top of Page



Top of Page

See Also