I like to think of ArcPad customizers and ArcPad developers as two types of people with different workflows in ArcPad.
ArcPad customizers are GIS integrators. They use ArcPad as an out of the box product and use the provided Quick Forms and ArcPad Studio to perform customization such as control placement of forms and perform rudimentary business rules such as input validation. At this level, customization is available by manipulating the layer form definition (i.e. APL / APX files) and encapsulating the business rules in your scripting language of choice (VBScript / JScript). The environment is rich so a lot of GIS projects can be delivered at this level of customization alone.
ArcPad developers are developers who like to leverage their skills to extend ArcPad out of the box functionality. The development options fall into broad categories:
- Developing ArcPad Extensions
- Developing ActiveX / COM objects
To build an ArcPad Extension, the developer is required to build a DLL with some expected entry points and placed them in a specific folder. How, where and why is covered in the documentation. Doing this will allow you to extend ArcPad's out of the box capabilities to make it support your prioprietory file format, GPS, Laser Range Finder, Projection method, Datum Transformation algorithm or leverage capabilities of your device's hardware or operating system. Traditionally, one would expect to do such customizations in native code C++ and you have the added benefit of leveraging from some UI elements from ArcPad in your extension such as ArcPad's Font Chooser and Symbology Chooser.
Alternative, one can consider building an ActiveX / COM object. There are well known techniques on this. i.e. you can develop them in C++ using the ATL Project template, or you can develop them in .NET (can be C#, VB, ...) using the ComVisible setting. Either way, once registered, you can access these objects from ArcPad scripting in VBScript / JScript. This approach is quite a common approach in other scripting disciplines so it's not exclusive to ArcPad. i.e. you'll be able to use the same ActiveX / COM objects in other solutions, such as HTML, ASP, Windows Script Host, VBA and other ActiveX technologies.
Both developing ArcPad Extensions or ActiveX / COM object allows developers to utilized their skills in their own environments for ArcPad. I'd say this approach is atypical for target ArcPad customizer end user. ArcPad Developers are more like consultants or 3rd party integrators who build such things either as a product of their core business or to support their core business.