I have created a custom HTML report template using test macros. Works great.
Apparently there are differences with the rendering of values between a regular HTML report template and a custom one.
I am using these macros in the custom report template.
%AverageReply%
%MinReply%
%MaxReply%
The regular HTML report template shows decimals and does not round up values as it uses 1 decimal place.
The custom HTML rounds up all values for all tests to whole numbers.
CPU Usage
Regular HTML: 8.7
Custom HTML: 9
Free Space (Not WMI)
Regular HTML: 117 Gb
Custom HTML: 125627793408 <---- ??? Can this be tuned up somehow in the custom report?
Is it possible to get the same results from a custom report template as the regular report template?
Regards
Custom HTML Report Template has Different Rendering
I'm not sure I understand.
I assumed that when using the macros in a custom report that the vaules would be the same as when using a standard report.
For what reason would anyone be unhappy with getting the same results between the two reports?
Though this is minor it represents inconsistent results between the two report methods of retrieving the same data.
As it stands now to use a custom html report for drive free space you need to use WMI instead of the convenient "Free Drive Space" test then tune it up to get a readable format such as 117 Gb. I have not tested this and maybe there is yet another way. Or this may not work at all.
As for the other test results like cpu mentioned here, it is a minor esthetic difference and not as precise. Personally I dont care, just pointing it out.
The free drive space result bothered me the most. I expected that value to be readable in the custom report as in the standard report. I'm sure this can be resolved with using a different approach. Again, just pointing it out as feedback. Long live hm.
Regards
I assumed that when using the macros in a custom report that the vaules would be the same as when using a standard report.
For what reason would anyone be unhappy with getting the same results between the two reports?
Though this is minor it represents inconsistent results between the two report methods of retrieving the same data.
As it stands now to use a custom html report for drive free space you need to use WMI instead of the convenient "Free Drive Space" test then tune it up to get a readable format such as 117 Gb. I have not tested this and maybe there is yet another way. Or this may not work at all.
As for the other test results like cpu mentioned here, it is a minor esthetic difference and not as precise. Personally I dont care, just pointing it out.
The free drive space result bothered me the most. I expected that value to be readable in the custom report as in the standard report. I'm sure this can be resolved with using a different approach. Again, just pointing it out as feedback. Long live hm.
Regards
We are not talking just about reports. We are talking about variables that you are using in report template.For what reason would anyone be unhappy with getting the same results between the two reports?
Somebody else can use these variables as parameters of some actions or ODBC query used for logging. If %MaxReply% shows 125627793408, it can be recorded into numeric field of database. If we change format, a lot of actions/logging can stop working because "117 GB" cannot be recorded as a number into database and so on...
So we should add new variables or change format for several special cases, like Custom HTML reports and HTML e-mail templates.
Regards
Alex
I undetstand the data is stored in raw format and you cannot store 117 Gb because that would not make sense.
What I would like to understand is how the standard report is coming up with a formatted result of 117 Gb. Is it not using the stored raw value then making some calculation? Somehow it is being tuned up under the hood right?
I agree that an additional macro is required or allowing macro calculations in the custom html report for tuning up results as desired. Some of these reports are sent to clients so 125627793408 does not make a whole lot of sense to them.
Regards
What I would like to understand is how the standard report is coming up with a formatted result of 117 Gb. Is it not using the stored raw value then making some calculation? Somehow it is being tuned up under the hood right?
I agree that an additional macro is required or allowing macro calculations in the custom html report for tuning up results as desired. Some of these reports are sent to clients so 125627793408 does not make a whole lot of sense to them.
Regards
Does it really make any difference how our code works internally?What I would like to understand is how the standard report is coming up with a formatted result of 117 Gb. Is it not using the stored raw value then making some calculation? Somehow it is being tuned up under the hood right?
I think you will not be able to change code anyway.
There is update for you: www.ks-soft.net/download/hm887.zip
You should have installed official version 8.86, then you may unpack hm887.zip and replace hostmon.exe and rcc.exe modules.
Regards
Alex
Thank you for the update. I'm not sure what was changed?
Regards
Not really, no. I felt that my explanation was misunderstood just a bit. I was merely being more direct to help the situation.Does it really make any difference how our code works internally?
That my friend is obvious.I think you will not be able to change code anyway.
Regards
Nevermind. I see the format is now readable.
In conclusion, I would like to see a way to "tune up" the presentation of the rendered values in the custom html report just as you can "tune up" test results.
I can only guess that not everyone uses custom reports to realize how beneficial this can be.
Regards
In conclusion, I would like to see a way to "tune up" the presentation of the rendered values in the custom html report just as you can "tune up" test results.
I can only guess that not everyone uses custom reports to realize how beneficial this can be.
Regards
1) in this unofficial update HostMonitor uses different format for these variables depending on where do you use them.Nevermind. I see the format is now readable.
Variables are "readable" only if you use them for Custom HTML reports or HTML e-mails so I hope other customers will be happy as well (in other words do not notice any changes in action/logging behavior)
2) I am not 100% sure but in official release we may keep everything as it was before and add several new variables.
Reason? Some mathematical calculations?In conclusion, I would like to see a way to "tune up" the presentation of the rendered values in the custom html report just as you can "tune up" test results
Regards
Alex
Well. The rendered data is raw. You dont really know what the unit of measure is because it is being read and displayed in its raw form.
When you are reviewing columns in reports you have to determine the value's unit of measure by reminding yourself what type of test it is by looking at the test name. If the units of measure were appended to the value, it saves your eyes from glancing over at a test name. This makes reviewing the report easier becaue you only have to look at the columns to know what type of test the value is for.
Possible modification:
I do not believe you need a new variable at all but rather change the behavior of the existing ones. I suggest the existing macros check to see if the test property has "Tune Up" enabled. If enabled, use the raw value and do a calculation within the code using the expression in the "Tune Up" field. The result will be the tuned up value however you want it displayed in the reports, emails or wherever the macro is used. I believe this is already true for emails and the reply field when looking at live tests. If "Tune Up" is not enabled then use the raw vaulue instead. If this method is used, one would not be able to have a tuned up value in emails and a raw value in reports since the macro will always use the "tuned up" expression wherever the macro it is used and whether "tune up" is enabled or not.
Or since the user can not control the how the values are rendered anyway just hardcode the units of measure in the code. Of course if this method is used it would only apply to things static like CPU, PING and not WMI, Script etc..
I believe it will improve the overall look of the reports and give better readability when viewing them.
Looking at a compiled report:
TEST AVG MIN MAX
CPU 4.9 0 100
PIMG 12 2 1254
TRAFFIC 12 2 20
Would be better to see:
TEST AVG MIN MAX
CPU 4.9% 0% 100%
Or for Ping tests
TEST AVG MIN MAX
PING 12 ms 2 ms 1254 ms
Or for Traffic tests
TEST AVG MIN MAX
TRAFFIC 12 MBit 2 MBit 20 MBit
When you are reviewing columns in reports you have to determine the value's unit of measure by reminding yourself what type of test it is by looking at the test name. If the units of measure were appended to the value, it saves your eyes from glancing over at a test name. This makes reviewing the report easier becaue you only have to look at the columns to know what type of test the value is for.
Possible modification:
I do not believe you need a new variable at all but rather change the behavior of the existing ones. I suggest the existing macros check to see if the test property has "Tune Up" enabled. If enabled, use the raw value and do a calculation within the code using the expression in the "Tune Up" field. The result will be the tuned up value however you want it displayed in the reports, emails or wherever the macro is used. I believe this is already true for emails and the reply field when looking at live tests. If "Tune Up" is not enabled then use the raw vaulue instead. If this method is used, one would not be able to have a tuned up value in emails and a raw value in reports since the macro will always use the "tuned up" expression wherever the macro it is used and whether "tune up" is enabled or not.
Or since the user can not control the how the values are rendered anyway just hardcode the units of measure in the code. Of course if this method is used it would only apply to things static like CPU, PING and not WMI, Script etc..
I believe it will improve the overall look of the reports and give better readability when viewing them.
Looking at a compiled report:
TEST AVG MIN MAX
CPU 4.9 0 100
PIMG 12 2 1254
TRAFFIC 12 2 20
Would be better to see:
TEST AVG MIN MAX
CPU 4.9% 0% 100%
Or for Ping tests
TEST AVG MIN MAX
PING 12 ms 2 ms 1254 ms
Or for Traffic tests
TEST AVG MIN MAX
TRAFFIC 12 MBit 2 MBit 20 MBit
If we are still talking about %AverageReply%, %MinReply% and %MaxReply% variables then such "option" can lead to a total mess.I do not believe you need a new variable at all but rather change the behavior of the existing ones. I suggest the existing macros check to see if the test property has "Tune Up" enabled. If enabled, use the raw value and do a calculation within the code using the expression in the "Tune Up" field. The result will be the tuned up value however you want it displayed in the reports, emails or wherever the macro is used.
Regards
Alex
