As guy already mentioned you need a hf field in order for the fields
to be filterable othervise proto_tree_add_text() can be used but you
lose all filtering capability.
Since all hf fields are generated at run time but most often this is
done during protocol registration
it should be possible to do something like which may be what you require :
When the dissector sees that it is a packet of type Y, and if the
descriptions for the fields for Y has not yet been loaded;
Read some external text file that contains the hf descriptions for Y;
Build a new hf array at runtime dynamically and register this new hf array
Continue the dissection using the newly loaded and registered hf fields
On 10/10/06, John R. <jhoger@xxxxxxxxx> wrote:
I have an existing dissector which has an hf table entry for every
possible parameter... and there are a lot of optional parameters in my
protocol. I have parsable descriptor files for the protocol, and the
protocol is gradually evolving even while we ship units which
implement it.
I'd like to revise my dissector to read these descriptor files
dynamically at runtime and use a heuristic function to determine which
version of the descriptor files (if the right version is available)
should be used.
I was hoping I could just have a few hf table entries for the fixed
portions of the header. But it seems that all of the
proto_tree_add_xxx functions expect a hf id. Is it possible to add
entries to the tree control that are not based on an hf entry? Would
I lose the ability to search for particular values?
If that's not possible to do without losing searchability (i.e. by
simply composing the entire tree control of custom formatted strings)
is it possible to dynamically create new hf entries at runtime?
Thanks,
-- John.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev