More recently, I have a customer who requires code maintenance with a better workflow for supporting a current release as well as a road map feature set for future releases. It became obvious that I had to improve my subversion tactics and embrace the more traditional subversion implementation with a trunk, branches, and tags.

I spent last weekend diving into the Subversion online book as well as scouring Stack Overflow . I ended up creating a document for my own best practices. I am now sharing it with the world. I hope you find it useful.

PDF for subversion best practices by Reynoldson Control Inc.

Eliminate array bounds

We don’t care about defining the parameters with any bounds for arrays. So you can change from this:

DEFINE_FUNCTION myFunc (CHAR cTxt[MAX_LEN])

to this:

DEFINE_FUNCTION myFunc (CHAR cTxt[])

Passback values

Any parameter that is modified within the function is “passed back” with the new value. Sometimes this can be dangerous and create a tricky bug to track down, but if you understand it you yield more power in the toolbox.

DEFINE_START

Code execution within the DEFINE_START executes first with the main AXS program (followed by any AXI files included in order compiled). Any modules will execute DEFINE_START after the main AXS program (and I assume in order defined by the AXS).

DATA_EVENT (ONLINE)

Modules seem to generate ONLINE events first, followed by the main AXS program.

We can use this to our advantage in that a module can define the default configuration settings. Then the main AXS file can overwrite these settings with it’s own online event that follows. Of course that means that some of the module initialization may be lost due to a mismatch in configurations (i.e. baud rate). Therefore it’s a good idea to wait for a ‘REINIT’ command following an ONLINE event.

//-----------------------------------------------------
// Relative level ramping with bounds check.
//-----------------------------------------------------
DEFINE_FUNCTION levelStep (SINTEGER snValue, SINTEGER snStep, SINTEGER snMin, SINTEGER snMax)
{
  snValue = snValue + snStep

  IF(snStep > 0) {
    IF(snValue > snMax)
      snValue = snMax
  }
  ELSE {
    IF(snValue < snMin)
      snValue = snMin
  }
}

It’s also a good idea to have a function for discrete level setting:

//-----------------------------------------------------
// Absolute level set.
//-----------------------------------------------------
DEFINE_FUNCTION levelSet (INTEGER nChn, SINTEGER snValue)
{
  uLvl[nChn].snValue = snValue

  SWITCH(nChn) {
    CASE LVL_PGM : SEND_STRING dvMXR,"'LVL_PGM-',ITOA(snValue)"
    CASE LVL_MIC : SEND_STRING dvMXR,"'LVL_MIC-',ITOA(snValue)"
  }
}

Then it’s easy to implement with button events:

//-----------------------------------------------------
// Program volume (0-100).
//-----------------------------------------------------
BUTTON_EVENT[dvPNLs,24]     // Vol Up
BUTTON_EVENT[dvPNLs,25]     // Vol Down
BUTTON_EVENT[dvPNLs,26]     // Vol Mute
{
  PUSH :
  {
    SWITCH(BUTTON.INPUT.CHANNEL) {
      CASE 24  : {
        TO[BUTTON.INPUT]

        levelStep (uLvl[LVL_PGM].snValue, 1, 0, 100)
        levelSet  (LVL_PGM, uLvl[LVL_PGM].snValue)
      }
      CASE 25  : {
        TO[BUTTON.INPUT]

        levelStep (uLvl[LVL_PGM].snValue,-1, 0, 100)
        levelSet  (LVL_PGM, uLvl[LVL_PGM].snValue)
      }
      CASE 26  : {
      }
    }
  }
  HOLD[3,REPEAT] :
  {
    SWITCH(BUTTON.INPUT.CHANNEL) {
      CASE 24  : levelStep (uLvl[LVL_PGM].snValue, 5, 0, 100)
      CASE 25  : levelStep (uLvl[LVL_PGM].snValue,-5, 0, 100)
    }

    IF(BUTTON.INPUT.CHANNEL <> 26)
      levelSet  (LVL_PGM, uLvl[LVL_PGM].snValue)
  }
}

More investigating revealed that multi-edit keyboards with pre-loaded values are possible. Here’s the text field properties to use:

• Assign the button a type of “Text Input”. This allows it to be selected (focus) and have the text value editable.
• Assign the button a variable text value. This is used for pre-loading the value from Netlinx code.
• Assign the “Name” property a value to be pre-pended when the edit is done, as in KB_NAME-.
• Parse strings back from the touch panel and look for KB_NAME- to get the values. Be sure and look for an ABORT value, in case the person decides to cancel the edit.
• For some reason, this KB_NAME- is not displayed using netlinx diagnostics. Test code will reveal that it really does work though.

Original post on 09 April 2010

AMX touch panel keyboards and keypads allow editing of a single item. You can customize a system page template to allow editing of multiple items, such as a telephone speed-dial entry for a person’s name and number. It works, but with some drawbacks.

GUI Tweaks

First off, open up the system page template and copy the __keyboard popup into your touch panel file. You will want to rename it (otherwise any @AKB or AKEYB command will use the new multiple edit keyboard). I’ll rename the new popup to ‘kbSpdDialEditor’.

Open up the new popup and select the prompt at the top. We’ll need to change this to a static text label, say ‘Enter new name and number’. Unfortunately, we won’t be able to use the @AKB command.

Open up the new popup and select the text area button. Resize it, allowing room for a label next to it, like ‘Name:’. Reselect the text area again. It will have a variable text assignment as setup:multi-line text area.

With the button, we will assign the channel number for setup:text entry and modify the ON border color. This will enable highlighting of the current item being edited.

Next, we’ll modify the OFF text value to ‘KB_NAME’. The touch panel will use this value as the header with the value once the user presses DONE (i.e. KB_NAME-Chad Reynoldson).

Copy the label/button pair and paste it below. Rename the label and the OFF text value to ‘KB_NUMBER’.

Implementation

You can use either a send command (i.e. @PPN) or a pageflip assignment from a touch panel button to bring up the new kbSpdDialEditor popup. Each time the fields will be reset.

When the user presses DONE, you’ll see a string event with ‘KB_NAME-value’ and another with ‘KB_NUMBER-value’.

Drawbacks

It works well and moves this functionality into the touch panel file, which is where I prefer to off-load as much work as possible. Unfortunately it won’t allow us to pre-load the editable name and number with something we may have stored in netlinx code, something @AKB allows us to do. This presents a huge problem for the end-user.

We could overcome this with netlinx code, but that breaks the simplicity of off-loading the heavy lifting to the touch panel.

So this seems like an exercise to prove that it works. Unfortunately it has some drawbacks that takes us right back to where we started.