On Jan 25, 2010, at 1:37 PM, Brian Oleksa wrote:
> Does each packet have to have it's own hf_value..??
Each *packet* doesn't have to have its own hf_ value.
Each *field in the protocol* *is* supposed to have its own hf_ value.
> Or could I just use
> something like that following for all strings (hf_helen_text)..??
>
> { &hf_helen_text,
> { "Text", "helen.text", FT_STRING, BASE_NONE, NULL, 0x0,
> "Text", HFILL}}
You could, but that would be wrong.
It would mean that either
1) all text fields would look like
Text: {string value}
or
2) you'd have to use proto_tree_add_string_format() and do extra work for no benefit.
It would also mean that if somebody wanted to find packets where a *particular* string, such as the flow name, had a particular value, they couldn't just do
helen.flowname == "test"
> I am also fixing all the places where I used "hf_helen_length".
> What is wrong with using hf_helen_length (as this could be very generic)..??
What's wrong with it is that it's *too* generic. :-) See above.
> For example... would you create a hf_value such as (hf_helen_nos) for
> the following example..??
>
> // Number of Satellites:
> guint8 nos;
> nos = tvb_get_guint8(tvb,offset);
> proto_tree_add_uint_format(helen_sub_tree,
> hf_helen_length, tvb, offset, 1, 0,
> "Number of Satellites: %d", nos);
I would most definitely do so! That's how Wireshark dissectors are supposed to work.
> What would this hf_item look like..?? Would it look something like this..??
>
> { &hf_helen_nos,
> { "nos", "helen.len", FT_UINT8, BASE_DEC, NULL, 0x0,
> "nos", HFILL}},
No, it would look like
{ &hf_helen_nos,
{ "Number of Satellites", "helen.nos", FT_UINT8, BASE_DEC, NULL, 0x0,
"Number of satellites", HFILL}},
although the second "Number of satellites" could give more detail - it's used in tooltips as a description of the field.
