HLA bubble text doesn't display zero (0) value?

While experimenting with high-level analyzer (HLA) for quadrature decoder (see other thread), I noticed that a zero value didn’t display in the bubble text of my draft HLA:

as the zero value (0) was in the scaled_position data – see Data table view:

(Note: original thread only had position column showing, while technically scaled_position is output)

Some snippets from the analyzer python script:

  1. The result_types definition:
    result_types = {
        'QuadEncoder': {
            'format': '{{data.scaled_position}}'
  1. The AnalyzerFrame being returned:
        # Return the analyzer output data frame
        return AnalyzerFrame('QuadEncoder', frame.start_time, frame.end_time, {
            'position'       : self.position,
            'rate'           : self.rate,
            'scaled_position': self.scaled_position,  # this value is what should display in BubbleText
            'scaled_rate'    : self.scaled_rate

I’m fairly new to python, so maybe it is something obvious with the ‘format’ string … ?
OR - maybe the HLA python conversion to BubbleText can’t differentiate between a numerical value of zero (0) vs. an empty string, null character (‘\0’)?

So, if I actually want a numerical 0 to be displayed, what do I need to do differently?

[Edit] Note: when trying to find other references (such as this article about displaying special characters), I tried updating my result_types to:

    result_types = {
        'QuadEncoder': {
            'format': '{{{data.scaled_position}}}'

… but this still didn’t resolve the missing zero value (‘0’) display in the bubble text.

While trying various other things, I also managed to break it and get “Template renderer error” to display on the bubble text – so maybe the real question is: what syntax is actually being used to render/format the result_types string values for the format key and actually convert/display the bubble text?

Okay, I think I may have found a workaround:

        # Workaround to display zero value
        if self.scaled_position == 0:
            self.scaled_position = '0'

… based on a StackOverflow article about rendering zero using a mustache template.

The only side-effect for my extension that I noticed, is that the CSV export added quotes around the zero. However, I’m not familiar with internal python type/conversion behavior, and if this workaround might have undesired consequences for other extensions that actually want to keep/use the integer value internally vs. just convert it to a string to output it to an AnalyzerFrame and display it within the bubble text.

Here is an example of the side-effect to the CSV exported text, was (output is 0 as though zero is an integer value):

"Quadrature Encoder","QuadEncoder",0.2482546,7.6912e-05,0,12553.35174491749,0,25106.70348983498
"Quadrature Encoder","QuadEncoder",0.40034152,0.000109412,0,8738.50886084273,0,17477.01772168546

Now (output is “0” as though zero is a text/string value):

"Quadrature Encoder","QuadEncoder",0.2482546,7.6912e-05,0,12553.35174491749,"0",25106.70348983498
"Quadrature Encoder","QuadEncoder",0.40034152,0.000109412,0,8738.50886084273,"0",17477.01772168546

So, is the ‘Template Engine’ being used to format & render the bubble text based on Handlebars JS derived from Mustache, or is it something else?

Trying to answer that question, I did a different workaround that might be preferred (and seems to indicate that the ‘Template Engine’ is Handlebars JS or some other derivative):

    result_types = {
        'QuadEncoder': {
            # Workaround to output '0' rather than empty string ('') for zero (a 'falsy' value in python)
            'format': '{{#if data.scaled_position}}{{data.scaled_position}}{{else}}0{{/if}}'

The pattern is a bit ugly, but at least you don’t need to modify the source object, just handle the special case of a falsy value in python (see StackOverflow article on truthy and falsy for good list of other python values that may need this trick to get an integer zero output in bubble text vs. an empty string).

For additional reference, the draft copy of code can be found in the follow-up to the original thread: Analyser for quadrature encoder - #23 by BitBob

… which has the first work around commented out (changing self.scaled_position to ‘0’ (string) when value is 0 (integer)), and the follow-up one implemented (tweaking the 'format' setting as described above).

Your feedback & comments as to the preferred approach for dealing with this issue are welcome; I’m not sure how many others might have noticed a problem displaying a ‘falsy’ value (like 0) in HLAs – and whether this is something that should be managed natively inside the HLA engine itself vs. handled by each HLA on its own. Also, knowing some more details about the actual template engine / format string specification could help with future HLA developments & customizations (i.e., what’s the syntax specification of the 'format' string in the result_types for HLA classes?)

Hi @BitBob,

Sorry for the delay on this. This is a bug on our end where falsy values are not being rendered. We have a fix that will go out with the next release.

As a short term workaround, if you are only using integers, you should be able to explicitly convert it to an integer and have it display correctly. Floating point 0.0 will not render, though, which is what I believe you are seeing.


Hi @huffman

When I had (what I thought was) an integer value of 0, it didn’t seem to work. I didn’t go back and confirm the exact data type inferred by python, but I recall only explicitly using integer constants in my code. However, maybe the initial assignment to NumberSetting() made it a python float vs. int? Anyway, It only seemed to work as long as I had a string value.

Note: the HLA python code I used is attached in the referenced thread above, but it sounds like you’ve got a fix already in the works.

Meanwhile, any comments or insight on what the ‘Template Engine’ is, or any more details on the 'format' syntax that can be used for the result_types formatting in an HLA?