Configuration string syntax
Fortunately, DigiView does extensive error checking of all of the configuration strings when the plug-in is first loaded. Any errors are reported and the plug-in is unloaded. Most error messages point to the specific field within the specific string with the error. Debugging this portion is usually pretty easy and can be done without a debugger. Refer to Configuration Editors for the correct syntax.
Once the plug-in fully loads, the most common problem is getting fields out of sequence. If your plug-in ever sends back a field with an older timestamp than the previous field, an error is reported and the plug-in is disabled; no time-travel allowed. However, you can generate back-to-back fields with the SAME timestamp in some circumstances. The following sequences are allowed to have the same timestamp:
•StartFrame or StartField -> EndFrame or EndField (zero length field)
•EndField -> EndFrame (EndFrame over-rides)
•EndFrame -> EndField (EndFrame over-rides)
•EndField -> EndField (2nd one ignored)
•EndFrame -> EndFrame (2nd one ignored)
Unexpected formatting
All formatting is controlled by your SendField calls and the Field Formats you specify. If you add or delete field format specifications to the string list, it will throw off any references to them. Using enums (as opposed to using strl.push_back() calls and hard coded indexes) as demonstrated in the examples goes a long way toward eliminating these mistakes. As a bonus, it makes the code more readable and maintainable. However, using enums and direct indexing makes it easy to miss/skip an entry in the stringlist. These empty strings get converted to: '<empty>'. Generally, the application will complain about 'entry x has too few parameters: <empty>'
If some of your Lookup Table values are not printing, it could be due to a reference to an undefined table or an undefined index into a table. Of course, it could also be due to specifying the same color for the background and the font :)
Ignoring data.bytes[7]
Data.bytes[7] in the parse() calls holds a code that describes the type of event we are receiving. 0x90 means RAW DATA event and 0x80 means parser data event. We generally ignore the value of data.bytes[7] in the examples. This is OK because the framework guarantees that mini plug-ins will never receive raw data events and full plug-ins will never receive parser data events. Constantly checking would be a waste of time. Only hybrid plug-ins receive both types of events and need to differentiate between them.
If you take a mini or full plug-in example and convert it to a hybrid, then forgetting to qualify on byte 7 will cause total confusion. See the 'HalfDuplex' example to see how a hybrid plug-in handles the event type code.
