Hello Pascal and Harris, Personally I too would prefer to use 'ofx.command == "add"' so that there is no need to write more code. I'll just have to wait and see for the final decision. And thank you for the information on generated fields, I will read more based on the resources you referred.
@Harris: About your suggestion on having a drop-down menu for the possible values. Is the information on how to implement it available somewhere in the README files? Thank you very much, David On Tue, Aug 13, 2013 at 3:36 PM, Guy Harris <[email protected]> wrote: > > On Aug 13, 2013, at 12:06 AM, DbdM Tbt <[email protected]> wrote: > > > Good day to all. > > Please bear with me as I am still learning the ins and outs of > formatting dissector output. > > I have come across a discussion about hidden fields and generated fields. > > http://www.wireshark.org/lists/wireshark-dev/201110/msg00257.html > > > > I am curious about this because I have a filter requirement. > > > > Let's say there is a field called 'command' > > +---------+ > > | field 1 | > > +---------+ > > | command | > > +---------+ > > | field n | > > +---------+ > > > > 'command' can have 3 values. > > add (1), modify (2), delete (3) > > > > From what I have currently seen so far, the 'command' field is first > 'registered' through a 'static hf_register_info' variable into > proto_register_field_array() > > All named fields are registered that way. > > > So for the 'command' field it will look something like: > > { &ofx_command, { "Command", "ofx.command", FT_UINT32, BASE_DEC, > VALS(cmd_vals), NO_MASK, "Command", HFILL } } > > Hence, 'ofx.command' will become the filter name. > > > > Now I would like to create a 'convenience filter' (I don't know the > correct term) for the 3 values. > > ofx.command.add > > ofx.command.modify > > ofx.command.delete > > So that you can have, as a filter expression > > ofx.command.add > > to search for "Add" commands, rather than > > ofx.command == "Add" > > (or however you choose to capitalize it in cmd_vals)? > > > With what I know, I will implement this by: > > 1. register additional 3 'static hf_register_info' entries for each > filter. > > 2. and use hidden fields so that wireshark will display only 1 field. > > This will be so that the filter ofx.command and for example, > ofx.command.add (assuming the value is add(1)), will work simultaneously. > > > > But based on what I have read, hidden fields are deprecated and/or > discouraged (?). > > Yes - if the field is hidden, it isn't in the protocol tree, so you can't > see it through the part of the UI that shows you packet details, and you're > less likely to know that it exists; it only shows up in the drop-down menu > in filter fields and in the "Filter:" dialog box for the field. > > It would be nice if, for a field that has a set of values, the drop-down > menu would show you the known values for a field, so that if you've typed, > for example > > ofx.command == > > the drop-down menu would show you a choice of > > "Add" > "Modify" > "Delete" > > > How would more experienced dissector developers go around this? > > I would simply rely on being able to say > > ofx.command == "Add" > > > And from the discussion that I linked at the start, there is a mention > about 'generated fields' > > I tried searching in google and the archives for the above keyword but > no clear information as to what are they > > They are fields whose values don't directly correspond, or don't at all > correspond, to packet data. > > If, for example, you have a request/response protocol in which a request > has a request type value and a request ID, and a response has a request ID > giving the ID of the corresponding request and has *no* type value, you > might want to, for a response, display the type of request to which it's a > response. That type isn't part of the packet - you'd keep a table of > requests, giving the ID and type of the request, and look in that table to > find the request type - so, if it were put into the protocol tree of the > response, it'd be a generated field. > > If you were to calculate some value based on the value of one or more > fields in a packet, and display that value in the dissection, that would > also be a calculated field. > > > and how they are implemented > > They're implemented by calculating the value, calling proto_tree_add_XXX() > for the appropriate type value of XXX (e.g., "uint" for an unsigned > integer) with the value as an argument to put the value into the protocol > tree, and then calling PROTO_ITEM_SET_GENERATED() on the return value of > proto_tree_add_XXX(). > > > (how they look?). > > They're enclosed in square brackets in the packet details display, to > indicate that they're generated. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
