BitView

[]	= optional
(x..y)	= range
|	= one of the listed
&	= any number of the listed
#	= integral number
""      = string (request) delimiters (can be constants or SNMP requests)
''      = string (constant) delimeters optional
...	= last command can be repeated

[debug alive|both] [version #version(1..2) | (useid | fullmenu | noconfirm | notimeout)] [retry #retries] [loaddll "extern.dll"] [appname "name"] [about #line(1..3) "text" ...] -- comment @ multi line comment @ menudef 'name' { popup 'popup' { graph 'menutext' 'table' [#interval] chart 'menutext' 'table' [#interval] table 'menutext' 'table' [#interval] edit 'menutext' 'table' history 'menutext' 'table' run 'menutext' 'filename' 'parameters' wrun 'menutext' 'filename' 'parameters' macro 'menutext' 'macro' set 'menutext' 'variable' 'value' rundll 'menutext' '!dllproc()' popup 'popup' { ... } } ... } ... hubdef { [useget | usenext] [chassis [x y] [bitmap 'bitmap']] [pollpersec #polls] [pollint #pause] [menus { 'menuname' ... }] [load "SNMP_variable" 'internal_variable' ...] [print x y 'string'] slotgroup { numslots # | [count] "numslot_request" & slotpos { <position> } slottype "slottype_request" { 'response' ... uses slotdef 'slotdefname' [bitmap 'bitmap']|[color 'color'] ... default uses slotdef 'slotdefname' [bitmap 'bitmap']|[color 'color'] fail uses slotdef 'slotdefname' [bitmap 'bitmap']|[color 'color'] } slotdef 'name' { [load "SNMP_variable" 'internal_slot_variable'] [print x y 'string'] [menus { 'menuname' ... }] [hotspot at x y size w h { menucommand 'table' ['value/params']}] portgroup { numports # | [count] "numport_request" & portpos { <position> } porttype "porttype_request" { 'response' ... uses portdef 'portdefname' [bitmap 'bitmap'] | built_in_type ... default uses portdef 'portdefname' [bitmap 'bitmap'] | built_in_type fail uses portdef 'portdefname' [bitmap 'bitmap'] | built_in_type } portdef 'name' { [print x y 'string'] [menus { 'menuname' ... }] [mouse { right { menucommand 'table' ['value/params'] } left { menucommand 'table' ['value/params'] } center { menucommand 'table' ['value/params'] } }] var "variable_request" { varpos { <position> } 'response' uses bitmap 'bitmap' ... change uses bitmap 'bitmap' default uses bitmap 'bitmap' fail uses bitmap 'bitmap' } } ... } ... } ... } ... }
<filename>
A constant string for a valid file relative to the SNMPc HUBVIEW directory. Both ".." and "c:\" are acceptable.

<string>
Strings can be defined with either single (') or double (") quotes. In many places it doesn't matter which one you use. In most of the BitView scripts included with SNMPc, double quotes are used thoughout and single quotes are used only when necessary (read on to find out why). There are certain special characters that either SNMPc or BitView will recognize as escape sequences. For any SNMP variable request, the following characters can be used (BTW, you can use this request format for any dde applications you write):
  • @ Use different IP address than the one defined for this node
  • : Use different community string than the one defined for this node
  • | Given MIB name (don't search through entire database)

In addition to these, BitView defines some special characters:
  • $name Internal variable
  • !proc DLL procedure call
  • #name Internal variable collection

When a string is used in menu tables and parameters (not menu text), load, numslots, slottype, numports, porttype, and var commands, these characters are replaced. The dollar sign is a way of getting at internal variables.
  • $slot: current slot (either selected for menus or for requests)
  • $port: current port (either selected for menus or for requests)
  • $node: name of node BitView is running on
  • $addr: address of node (either IP or IPX)
  • $win: window handle of SNMPc
  • $arg1..3: 4th, 5th, and 6th parameters on command line (first is always node name, second should be SNMPc window handle and third is an optional fixed definition name to tell BitView not to look at the hubnames.txt file.)
  • $snmpcdir: directory where SNMPc is installed
  • $hubdir: directory for HubView files
  • $getcomm: get community for node as defined by SNMPc
  • $setcomm: set community for node as defined by SNMPc
  • $custom: is passed on since SNMPc custom table MIB names are $custom|

The exclamation mark is used to call functions from a
DLL. The hash mark (pound sign) is used to collect indexes when using the count flag on numslots and numports commands. The indexes returned are stored internally along with the current slot/port and can be retrieved using the dollar sign with the variable name. See either the numslots or numports definitions for further explanation. For instance:
   porttype "198.92.129.1@!resolve_comm($slot):RFC1213-MIB|ifType.$port"
is a valid variable request for BitView.
Where the type of quotes comes into play is wher BitView will be doing requests (load, numslots, slottype, numports, porttype, var). Double quotes will do an SNMP query to the device, whereas a single quote string will replace any internal variables and call any DLL procedures and return it's value right away without going out to the device. This is again explained where these requests are made. See also: menudef, load, numslots, slottype, numports, porttype, var.

<response>
'string' default fail change (only for var)

<position>
This is used with either slot, port, or variable position definitions. It consists of multiple lines of either single or sequential position definitions. A single position declaration looks like:
   n at x y [size w h] [select x y size w h] [bit b length l]
N is the index that will replace a $slot or $port in a request
string (make sure you are using the correct version). X and Y are the coordinates where this object should be (0,0 is in the upper left hand corner). All measurements are in pixels. Slot positions are relative to the entire chassis picture and port positions are relative to the slot they are in. Size is the area that can be selected: width and height. Select will let you specify a position and size that you can click on. If no sizes are provided, BitView takes the dimensions of the port or slot type bitmap. This is usefull if you are trying to get a 3d effect on the screen. You will want a module to appear in orthagonal view, but you only want the face selectable. All size measurements are ignored for variable positions since indicators are not selectable. Bit and length will allow you to select certain bit strings from a number. If you are taking bits from an octet-string of q bytes, they will progress from 0 to 8*q-1 going from most significant byte on the first byte to the least significant on the last. If the value you are getting bits from is a number, the bits will follow the PC mapping (from least to most significant). Bit is the offset to start looking at and length is the number of bytes to take. Results will be converted to base 10 for response comparison. Since most faceplates have objects evenly spaced along them, there is a way to define a group of positions sequentially.
   sequence { n at x y [size w h] space x y count c
	[select x y size w h] [bit b length l] }
N is the index to start with. X, Y, size, select, bit, and lenth parameters are identical to the previous definition style. Count is the number of times to repeat this object and space is the x and y offset of each object. Both methods can be used interchangably. The following is an example of a 13 port repeater that has 12 ports in a block and an extra port on the side.
   portpos {
      sequence { 1 at 50 10 size 15 15	space 20 0  count 12 }
      13 at 10 10 size 30 15
   }
   porttype "MAU-MIB|rpMauType.$slot.$port.1" {
      ...
   } 
See also: slotpos, varpos, portpos, porttype, slottype.

bitmap 'filename'
Most bitmap files will be a valid filename refrencing a standard Windows BMP file. The bitmap can be any number of colors, but will only be correctly mapped in 16 colors unless you are in a true color display mode. A BitView bitmap can consist of more than one file. Along with the main bitmap, you can also have Windows bitmaps with the extensions "MSK" and "BLK". The MSK extension will let you mask out the background. In the mask file, use white for the masked part and black where your image will go. For the bitmap, use black for the background. For example: background + MSK + BMP = finished product.
& | =
In this example case, it would have just been easier to include the gray background in the BMP file itself and make it smaller (). The other extension, BLK, is to create blinking lights. BitView will alternate between the BMP and BLK image on each timer tick. Thus:
& | ( + ) = and
Again, it would be easier to just use smaller bitmaps: ( and ). For each image you will need a file with a BMP extension. So if you wanted a solid green led and a blinking green led, you would need at least these files: GREENLED.BMP (), BLINKLED.BMP (), and BLINKLED.BLK (). Eventually, instead of using files, you will be able to get your bitmaps out of a DLL.

include 'filename'
This will insert text from file as if it had been typed there. It can appear anywhere in the script but should be on it's own line. If there is an error in the include file, BitView will display the correct line number, but the original file name.

loaddll 'filename'
BitView allows you to extend certain commands by writing your own functions in a DLL. Any string will allow you to call your function from the DLL listed in filename, and the string returned will appear in the string. Some examples would be a menu option that would pop up a dialog box to have the user set a variable:
   set 'Set SysName dialog' 'sysName.0' '!mydlg()'
or
   set "Enable Port" "slotStatusVar.$slot" "!PortCode(on)"
   set "Disable Port" "slotStatusVar.$slot" "!PortCode(off)" 
Another might be a repeater that has non-standard slot numbering. You could do this:
   porttype "MY-MIB|rptrGroupType.!findslot().$port"
This will allow you to look up the the correct slot number and return it to BitView which will do the request. I could go on listing examples for days, but this is a very powerful command and the possiblities are endless. This is an advanced feature and you should only use it if you are familiar with windows programming and DLL programming. The function definition should be:
int far pascal DllProc(HINSTANCE hInst, HWND hWnd, char *dest,
	char *node, int sg, int slot, int pg, int port, char *data);
When BitView calls your function, it will pass it's instance and window handle. Any window related functions you do (CreateWindow/CreateDialog) will have to use BitView's instance, not the DLL's instance (this is just a Windows thing). Also, you have to make you code re-entrant since multiple copies of bitview can run at the same time. You can use either the instance or window as a session handle if you need one since they will be unique to an instance of BitView. Any text in the parentheses will be passed verbatim to your function in the data parameter. Do not include any extra close parentheses in here. Node is the node name that bitview is running with. SG and PG are the slot group and port group associated with this call indexed from 1. Slot and Port are the current slot and port as taken from slotpos and portpos. The string you want substituted in the original request should be returned in "dest". Dest is an array of 256 characters. You should return non zero if your function is successful. If you return a 0, BitView will display an error message box if there is text returned in data. Here is an example function in C.
   int far pascal
   PortCode(HINSTANCE hInst, HWND hWnd, char *dest, char *node,
       int sg, int slot, int pg, int port, char *data)
   {
      if (port==0) {
	 strcpy(dest,"You must select a port.");  // since a port must be
	 return (0);				  // selected for this, print
						  // this error message.
      } else {
	 if (!strcmp(data,"on"))                  // special number that must be
	    sprintf(dest,"%d",2*port);            // set.  based on the port
	 else if (!strcmp(data,"off"))            // number. evens turn port on,
	    sprintf(dest,"%d",2*port+1);          // odds turn port off
	 else {
	    strcpy(dest,"Parameter must be either 'on' or 'off'.");
	    return (0);
	 }
      }
      return (1);
   } 
This command is optional and if used, must appear at the top level. See also: string, rundll.

debug alive | both
When developing a BitView script, it is often usefull to see what the script file is doing behind the scenes. If this command is used, BitView will create a file in your SNMPc directory called BITVIEW.LOG that will contain the information. The contents of this file are not documented yet, but if the file is sent to the Castle Rock tech support staff, we can probably tell whats going wrong. There are four levels of debug information. Alive will show a bliking light on the menu bar whenever BitView is processing requests. No data will be saved, but the user can see if BitView is still functioning. Both will Save data on dde requests, internal state, item selection, and menu commands in addition to showing the blinking light. Originally BitView had seperate flags for dde and state data and "both" would select them both but one is usually useless without the other. This command is optional and if used, must appear at the top level.

version #version(1..2) | useid | fullmenu | noconfirm | notimeout
BitView is an evolving product and as such, backwards compatibility must be maintained while adding new features. This is what the version command is for. It can be followed either by a number or by any number of features. All new features are off by default so old scripts will still work correctly. Originally, BitView only did requests for ports or slots with sequential numbers. However, it is useful to be able to type the indexes you want right into the slot, port, or variable positions. To use the position indexes for requests, include the useid feature. Also, the menus for each definition are usally additive (if you select a port, the menus for that slot and the main menus are automatically used in addition to the port menus). If you specify the fullmenu feature, each menu call must include all the menus you want displayed. Here is the old way:
   hubdef {
      menus { 'main' }                          -- main
      slotdef {
	 menus { 'slot' }                       -- main + slot
	 portdef {
	    menus { 'port' }                    -- main + slot + port
	 }
      }
   } 
With the fullmenu feature you can do this:
   hubdef {
      menus { 'main' }                          -- main
      slotdef {
	 menus { 'slotmain' }                   -- slotmain
	 portdef {
	    menus { 'slotmain' 'port' }         -- slotmain + port
	 }
      }
   } 
Noconfirm will not ask the user yes or no for any set commands. Notimeout will not inform the user when the timeout's occur, but instead it will create a fail state in whatever was polling. When the version was first introduced, it took a number as an argument, either one or two. One was the normal bitview and two used the new features. This does not let you select the features you want and the only reason it was included was for backward compatibility. Version 2 is equivalent to the fullmenu and useid flags. This command is optional and if used, must appear at the top level. See also: slotpos, varpos, portpos, menus.

retry #retries
This is the maximum number of times BitView will attempt a request before giving up. The default is taken from SNMPc when BitView starts up.

appname 'string'
Normally BitView will put the text "BitView" in the caption of the window. With this you can change the title to whatever you want. It will appear with the node name in this format: "AppName - NodeName".This command is optional and if used, must appear at the top level.

about #line(1..3) 'description'
Just as the application name can be customized, you can change the contents of the about box. The first three lines can be changed. The copyright and version number are always present. The default is "", "BitView", "Graphical Device Interface". This command is optional and if used, must appear at the top level.

menudef 'menuname'
The menus in BitView are completely customizable and are also context sensitive. Each menu definition is given a name that can be associated with the chassis, slot, or a port with the menus command. Each menudef consists of any number of popup menus (no selectable menu items are allowed in the menu bar). All text appearing in the menus is fixed and no string replacement will be done since the menus are created before BitView has the information. However, table names and values will be converted. It is common to include either a slot or port reference ($slot, $port) in the table name. This allows you to perform the action on the currently selected object. Since the menus are context sensitive, you should try to only display tables using selections when the associated object is selected. You can have as many menudef as you want.

hubdef
This is the keyword that starts the graphical representation of the device. There can be only one, and it must appear at the top level.

useget or usenext
This tells BitView to use either GETs or GETNEXTs when trying to request multiple variables at the same time. By default it uses gets. If using gets and a request fails, SNMPc will try to get one variable at a time which is much slower. If using getnexts, it will usually do one request, but there may be indexing problems (BitView will use $slot-1 for slottype and $port-1 for porttypes and var). You can see what BitView is trying to request by using the debug statement.

chassis x y bitmap 'bitmap'
This describes how the background of the window should look. You can specify either a size and/or a bitmap. If no bitmap is defined, the background will be black. If no chassis size is defined either, BitView will try to compute the size based on the numslots parameter.

pollpersec #polls
This is the maximum requests BitView will try to do per second. The default is 10. BitView only has one request outstanding at any time so if a response is lost, BitView will pause (not hang) until it does a retry.

pollint #seconds
BitView usually loops though the hub display continuously. If you specify a poll interval here, BitView will pause for this many seconds before it updates the display again.

print x y 'string'
Prints text for entire hub, slot, or port at the given x y coordinates (port coordinates are added to the current slot's). It will replace any special string with the appropriate text. It prints a 5x5 pixel font in reverse colors.

menus { 'menuname' ... }
Menus are chosen for display with the menus command. In each "def" section (hubdef, slotdef, portdef), you can specify which menus you want to use. The menu names from from the menudef definitions. If you specified the fullmenu version, you must specify all the menus displayed at each level. Otherwise, the menus are additive (the associated slot and hub menus are displayed when a port is selected).

load "SNMP_Variable" 'internal_name'
This is used to load SNMP data into strings locally accessable with the dollar sign. This is usefull if you have to load the community name to use from the device or if there is a status variable for a slot that describes all the ports. It can be called from the hubdef or slotdef section. If called from the slotdef, it remembers which slot and slotgroup it got the data from so one variable name can contain a value for each slot. Here is the example for loading the global community name that would be called from the hubdef:
   load "MY-MIB|readCommunityName.0" 'community'
Now wherever you did requests in your script, you could use "$community:" in front of the variable to use the community name you read in. An example of a slotdef load is:
   load "MY-MIB|slotStatusVar.$slot" 'slotstatus'
Now for the port status, instead of doing requests for each port, you would use a single quote string (no SNMP request) to indicate status.
   var '$statusvar' {
      varpos {
	 1 at 50 20 bit 0 len 2      2 at 60 20 bit 2 len 2
	 3 at 70 20 bit 4 len 2      4 at 80 20 bit 6 len 2
      }
      "0" uses bitmap "status1.bmp"
      "1" uses bitmap "status2.bmp"
      "2" uses bitmap "status3.bmp"
      "3" uses bitmap "status4.bmp"
   }

slotgroup
One or more slotgroup entries define groups of related slots or modules within a device. Usually there is only one slotgroup. Each slotgroup has subsections that specify slot positioning, the MIB variables and values that identify a slot type, and the slot type definitions.

numslots # | [count] "numslot_request"
The numslots entry specifies the number of slots in the group. If slotpos is not defined, BitView automatically calculates the slot sizes based on the images that are used to display each slot. If you put a numerical value or a single quoted string here, BitView will use that value as the number of slots. If you use a variable string here, BitView will look up the variable and use the returned number as the number of slots. If you use the count flag, things work differently. BitView will do GETNEXTs on the variable until there are no more entries in the table and use the number of iterations to calculate the number of slots. For example:
   numslots count "RFC1213-MIB|ifIndex.#portid"
This will see how many interfaces there are, and save each of the indexes in an internal variable "portid" that can be used like this:
   slottype "RFC1213-MIB|ifType.$portid" { ... 

slotpos
This determines the positions of the slots. The numslots parameter overrides the number of slots defined in slotpos. See position.

slottype "slottype_request { response }"
The slottype entry specifies a MIB variable that is used to find out what kind of module is currently available in a slot. There is one line for each slot type. Each line specifies a list of values for the slot type variable that map onto a particular module type, a bitmap file or color to use for the module type, and the slot definition name, which selects the corresponding slotdef for the module. The fail entry specifies what to use when the SNMP request fails for the slot, and the default entry specifies what to use for all unlisted return values.
   slottype "MY-MIB|slotType" {
      "UTP" uses slotdef "def1" bitmap 'mydir\slotpic1.bmp'
      "COAX" uses slotdef "def2" bitmap 'bitmap\slotpic2.bmp'
   }

slotdef 'name'
There is one slotdef section for each possible module type. Each slotdef has a unique "name" which identifies the module type. This name is the same as the named supplied in the slottype section.

hotspot position { menucommand }
One or more optional hotspot entries define areas where you can double click the mouse left button on, and an associated command that is executed. The command has the same format as any of the basic menu items, except that the menu name string is missing.
   hotspot at 10 50 size 20 20 {
      SET "MY-MIB|portAdminStatus.$slot.$port" "enabled"
   }

portgroup
One or more portgroup entries define groups of related ports within a module. Usually there is only one portgroup section. Each portgroup section has subsections that specify the number of ports in the group, the position of each port, the MIB variable and values used to identify a port type, and the port definitions.

numports # | [count] "numport_request"
Basically the same as the numslots section, but on a port basis. See numslots

portpos position
Basically the same as the slotpos section, but on a port basis. See slotpos.

porttype "porttype_request { response }"
Basically the same as the slottype section, but on a port basis. See slottype.

portdef 'name'
Basically the same as the slotdef section, but on a port basis. See portdef.

mouse { <button> { menucommand } }
The optional mouse entry specifies commands to execute when the left or right mouse buttons are double clicked on a port of this type. The command has the same format as any of the basic menu items, except that the menu name string is missing.
   mouse {
      LEFT { GRAPH "RFC1213-MIB|IfEntry.1" }
      RIGHT { CHART "RFC1213-MIB|IfEntry.1" }
   }

var { varpos { position} response }
One or more var entries specify a MIB variable to query, and the graphical action resulting from different returned values. This entry is normally used to draw LEDs or different state-dependent port images. There is generally several var entries, with at least one for each of the port Link, Partition, and Enable state. Additionally, there may be var entries to indicate collisions or line traffic. The varpos entry specifies the x y location of each numbered LED or state-dependent port image. For the latter, the location would be the same as the portpos locations. If multiple var entries have the same varpos locations, only the last matching var entry will affect the displayed image. Following the varpos entry there is one or more value lists that specify what bitmap to display when a certain value is returned for the variable. Each value list maps one or more values onto a bitmap file. The special value, "*" can be used to match any values that is not specified in a value list. The special value change can be used to match any value that changes, and is normally used with variables that count things like collisions or packets. If there is no matching value list then the var entry has no visual effect.
   var "MY-MIB|portAdminStatus.$slot.$port" {
      varpos {
	 1 at 10 50
	 2 at 20 50
	 3 at 30 50
	 4 at 40 50
      }
      "on" uses bitmap "mydir\porton.bmp"
      "off" uses bitmap "mydir\porton.bmp"
   }