In a template I am writing, I wish to highlight checksum data which doesn’t match a calculated checksum, and to show the “Calculated Checksum” in the comment when it doesn’t match. The checksum in the file appears at the start of the given block, so I pre-load it into a byte array to calcualte it, then use FSkip(-n) to reverse so that the actual data values can also be parsed.
Currently, the best I can do is to create conditional bgcolor and fgcolor.
‘comment’ doesn’t appear to reference any local variables - neither for the string to display, nor within the conditional to choose whether or not to display it. I understand from another question in this forum that this is done because you don’t want to keep too many strings around. I am able to put the calculated checksum at the structure level, but this is not as good as putting it right at the checksum field within the struct. I’m not sure whether there is a better way…
It would be better to display “good”/“bad” based on styles - could you implement a “sError” or “sBadData” style ? Something like red foreground on block background for the default color style set…
Does ‘style’ have a data type that can be assigned (in the same way that bgcolor/fgcolor is ‘int64’ behind the scenes) ?
I was going to ask whether there was a hotkey to re-run the same template to re-validate, but I just realized that F5 does the trick. (Thanks for including this !)
Hello dshadoff. You can change the color of the variable with the fgcolor/bgcolor attributes and you can change the comment using the comment attribute. Comment functions should be able to access local variables but note that comment functions are run after the template has finished, so it’s important where the local variables are stored. You should most likely store the local variables inside each struct instead of having a global variable. If you can’t get it working you may have to post or email us some code so that we can see what is going on.
We may add in some more styles in the future but for right now you can create your own syntax styles using the ‘Theme/Colors’ page of the Options dialog. Then in your template you can get the colors of the styles using HighlightFindStyle, HighlightGetStyleForeColor, and HighlightGetStyleBackColor and then use those colors for fgcolor/bgcolor. You cannot currently create your own template styles and there is no real datatype that you can assign to the style attribute.
Thank you for your responses and for your consideration about future features.
With respect to the comment field not having access to local variables, I have uploaded a template and a corresponding test file to a temporary GitHub repository (I am not able to attach them here):
I am happy to delete the repository at such time as it is no longer needed.
I get the error “*ERROR Line 71: Function or variable ‘chksum_ok’ is undefined”, if the comment makes a reference to a local variable - either as part of a conditional (as shown), or even if it directly references the string ‘cmt_msg’ for the whole message. Note that the local variables are not hidden (I considered that this might have been a possibility).
Note that all entries in the file are valid, except entry which intentionally has a 0x01 value to force a bad checksum. However, the error happens for all iterations regardless.
From your response, I get the feeling that this is a bug, rather than how the feature was expected to behave.
This is not quite a bug, but it’s not working quite like you expect. The problem is with this line:
WORD wChecksum <bgcolor=checkBgColor,
comment=(chksum_ok ? "OK" : "BAD"), format=hex>;
A comment attribute is basically a function that takes wChecksum as an argument and it currently can’t access other members of the struct like ‘chksum_ok’ by default. You can get around this by using ‘parentof(this).checksum_ok’ to access that variable. This should work:
WORD wChecksum <bgcolor=checkBgColor,
comment=(parentof(this).chksum_ok ? "OK" : "BAD"), format=hex>;
In the future we’ll take a look and see if we can automatically scope variables like this.
Thank you for your response, this looks like a very helpful approach to use for situations like this.
To be honest, I was only confused because the same types of references were working for bgcolor and fgcolor.