On Tue, Jan 02, 2001 at 10:13:33PM -0500, Ed Warnicke wrote:
> Third, I've found that the full name of the protocol is
> not always very useful. For example, how confused is a user looking
> for DHCP going to be? I know this problem is bigger than the new
> filter construction dialog, but I decided to take this opportunity to
> complain anyway.
OK, I've just checked in part of a change I've been working on for a
while - "proto_register_protocol()" now takes an additional argument,
which is a "short name" for the protocol (for showing to people, so it's
not all-lower-case like the abbreviation), and it builds a list - sorted
by protocol short name - of data structures, one per protocol.
The filer construction dialog box uses that list and uses the short
names rather than the full names; the code to construct the
"Edit->Protocols" dialog also uses that list, but it still uses the
abbreviation for now (using the short name requires a larger window; I
did a version of the code that did so, *and* that put the table of
buttons into a non-scrollable window so that it always came up big
enough to show all the buttons, but I'm a little nervous that it may
take too much space on smaller screens).
The short name could also eventually be used elsewhere, e.g. it could be
used to set "pinfo->current_proto" (which would require that the
protocol's index or its data structure and the dissector somehow get
connected, so that the code to call a dissector via a handle or via a
dissector table could set "pinfo->current_proto") and used as the name
in the preferences tab for the protocol (I think that one can be done
now).
The protocol data structure also has the "dissection enabled" flag, so
if the protocol and the dissector are associated, the code to call a
dissector via a handle or a dissector table could also do the
"CHECK_DISPLAY_AS_DATA()" stuff.
This does, however, require that every such dissector be associated with
one and only one protocol, and *vice versa*; there are currently some
exceptions to that....
