You may have noticed "proto_tree_add_item_ret_display_string()" and perhaps found that it doesn't do what you want; it produces the display string for a default display representation and doesn't use your custom function. (Perhaps it should?)
On Tue, Sep 12, 2023, 10:05 AM John Thacker <johnthac...@gmail.com> wrote: > In general you don't want to do that, if your goal is to create an expert > info. The string would not exist and thus the Expert Info would not show in > the "Analyze -> Expert Information" dialog, or in other situations where > the tree was not visible and the item was faked; you might have to > specifically filter for the item. (See > https://gitlab.com/wireshark/wireshark/-/issues/18955 for a similar > situation. Also somewhat relatedly > https://gitlab.com/wireshark/wireshark/-/issues/19216 ) For optimization > purposes, strings and display labels are not filled in unless necessary. > > What you could do is allocate your own string buffer, and pass it and the > uint64_t to your Receive_Frequency function. You can simplify that by > replacing your proto_tree_add_item() call with: > > uint64_t value; > char[ITEM_LABEL_LENGTH] label; > ti = proto_tree_add_item_ret_uint64(tree, hf_, tvb, start, length, > encoding, &value); > Receive_Frequency(label, value); > if (....) { > expert_add_info(pinfo, ti, &ei_); > } > > However, since it's processor intensive and error prone to convert to a > string only to parse the string back to floating point, you'd probably be > better off retrieving the uint64_t value and passing it to a function that > converts it directly to the floating point you need, separate from your > custom display function. > > Cheers, > John Thacker > > > On Thu, Sep 7, 2023 at 12:15 PM John Dill <john.d...@greenfieldeng.com> > wrote: > >> I have a question whether I can get the dissected string of the >> BASE_CUSTOM header field so that I can do analysis on it and convert it to >> floating point to do range analysis so I can issue an expert info if the >> value is valid but out of range. >> >> >> { >> &hf_Receive_Frequency, >> { >> "Receive Frequency", >> "Receive_Frequency", >> FT_UINT48, >> BASE_CUSTOM, >> CF_FUNC(Receive_Frequency), >> 0x0, >> NULL, >> HFILL >> } >> }, >> >> ... >> >> ti = proto_tree_add_item(word_tree, >> hf_XTS_5000_APX_8000_Receive_Frequency, tvb, offset, 6, ENC_BIG_ENDIAN); >> >> ... >> >> static void Receive_Frequency(gchar *result, guint64 value) >> { >> guint16 w_Base_Frequency; >> guint16 w_1_MHz_BCD; >> guint16 w_100_KHz_BCD; >> guint16 w_10_KHz_BCD; >> guint16 w_Rx_KHz_Frequency_Field; >> >> guint32 MHz_Frequency; >> guint32 KHz_Frequency; >> >> ... processing ... >> >> switch (lut_Base_Frequency[w_Base_Frequency]) >> { >> case -1: >> g_snprintf(result, ITEM_LABEL_LENGTH, "Illegal"); >> break; >> >> case 0: >> g_snprintf(result, ITEM_LABEL_LENGTH, "Invalid"); >> break; >> >> default: >> /* Frequency is typically displayed in MHz with 4 significant >> digits */ >> g_snprintf(result, ITEM_LABEL_LENGTH, "%" G_GUINT32_FORMAT ".%" >> G_GUINT32_FORMAT " MHz", MHz_Frequency, KHz_Frequency / 100); >> break; >> } >> } >> >> Is there a way for me to peel the dissected result string from "ti" after >> the proto_tree_add_item call so that I can do validation and range checking >> for expert info? >> >> Can I try to hijack proto_item_fill_display_label to somehow push "tmp" >> out of the interface into a proto_tree_add_*_ret_processed_string? >> >> \code >> if (FIELD_DISPLAY(hfinfo->display) == BASE_CUSTOM) { >> gchar tmp[ITEM_LABEL_LENGTH]; >> custom_fmt_func_t fmtfunc = (custom_fmt_func_t)hfinfo->strings; >> >> DISSECTOR_ASSERT(fmtfunc); >> fmtfunc(tmp, number); >> >> label_len = protoo_strlcpy(display_label_str, tmp, label_str_size); >> \endcode >> >> This 'tmp' from fmtfunc is the string I want to grab for post-analysis, >> but it seems non-obvious how to get at it. >> >> I might be completely overlooking an easy way to do this. >> >> Any suggestions? I already maintain a fork, so having a custom mod to >> pull this out is on the table for me. >> >> Thanks, >> John D. >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
