On Mar 31, 2009, at 8:28 PM, gogrady@xxxxxxxxx wrote:
i am creating a dll interface between wireshark plugin and the
protocol lib, it returns the human readable information because that
is what is needed for the more important programs that my company is
developing.
That's *all* that's needed? And they won't make changes to allow the
DLL to be used conveniently in protocol analyzers as well?
There are ways in my dll and lib to get the size of the raw data so
that when i highlight in wireshark it highlights the correct bytes
in the raw data section, i have functions that i can pass to the
proto_tree_add_'s for length that do this, and i have a variable
"offset" that keeps track of the current placement in the raw data.
The design is and must stay as the raw data is passed plugin ->
interface -> lib and then the human readable char * or int from lib -
> interface -> plugin and must be done as so. Unless you have
another idea for outputing these types to make filterable, it seems
to me that the only way is to use the hidden items along with the
add_text.
The idea that I've already mentioned is that:
for the cases where the library returns an int, if the int value is
the raw data for the field, use it in proto_tree_add_uint() or
proto_tree_add_int();
for the cases where the library human-readable string, parse the
human-readable readable string to get the actual value on which you
want to filter.
The hidden items won't help here, as, to make them filterable, you'd
need a value to put into them; if you have that value, you can just
put it into the regular protocol tree item, using proto_tree_add_
{something other than text}. If you want to use the string that the
library returns as the display string for the item, use
proto_tree_add_format_{something other than text} or
proto_tree_add_format_value_{something other than text}, so that the
protocol tree item has the int value you got from the routine or the
value you got by parsing the string returned by the library, but is
displayed with that string.
