Stephen,
Nice feature. For me, the column naming convention wouldn't be a problem, but maybe it'd be nice to be able to name it something else, especially if the display filter name is long. I think it would also be better to not allow invalid display filter names to be entered. That way, simple typos, etc. are avoided and the user is not wondering why nothing is ever displayed in the column.
BTW, I added a column called, "ip.ttl", then tried to sort on that column. It did not sort according to how I would expect. Rather than sorting 1, 57, 58, 60, 64, 107, 118, 127, 128, 193, 246, it sorted 1, 107, 118, 127, 128, 193, 246, 57, 58, 60, 64. So the sort seems to be operating on the field as if it's a string rather than a numeric value.
Another thing that might be improved upon is to alphabetize the drop-down list of available formats so they're a little easier to find. Since the drop-down list seems to be getting longer, another possible improvement might be to switch from a drop-down list to a toolbar-choice-style selection whereby all available columns are listed in alphabetical order on the left pane, and the right pane has the currently displayed columns in the order to be displayed. The two panes would each have a scroll-bar (if needed), and the long, somewhat cumbersome drop-down list would be eliminated. Buttons in between the panes would be used to "Add -->" or "<-- Remove" column choices. Just a few ideas.
- Chris
________________________________
From: wireshark-dev-bounces@xxxxxxxxxxxxx on behalf of Stephen Fisher
Sent: Mon 2/11/2008 10:36 PM
To: wireshark-dev@xxxxxxxxxxxxx
Subject: [Wireshark-dev] New feature: custom columns
I have introduced a new feature that I think people will really like
(and has been requested in one or two open bug reports.) It lets you
specify any display filter name as a column by choosing the Custom
column type and putting the display filter name in the description. For
example, go to preferences and add a new column type of custom and put
http.request.uri in the description field. Any http packet with an
http.request.uri field will have its contents displayed in the new
column. It is not yet complete (as explained below), but I wanted to
get it out to everyone to start testing / making suggestions for
improvement on.
I have kept it simple so far in that there is not even a prompt of where
to put the display filter name once you choose a custom column. Any
suggestions on how to improve this? Also the column title has to be the
display filter name right now. If an invalid display filter is entered,
it is silently ignored and a blank column will appear.
Coloring rules do not have to be enabled to see the data from these
fields because the presence of one or more custom columns causes tree to
be created (!= NULL) just like the coloring rules does. This means that
custom columns should be disabled when looking for the highest
performance from Wireshark.
NOTE: There are many fields that are not implemented yet in
epan/proto.c. I will work on finishing these as my time permits.
Anyone else is welcome to work on it also :-). The trick is to call
col_custom_set_fstr(fi->hfinfo->abbrev, "[Format such as %s]", value)
from within proto_tree_set_* functions. Keep in mind that some
proto_tree_set_* functions call others (such as
proto_tree_set_string_tvb calling proto_tree_set_string), so the
col_custom_set_fstr call only has to go in the proto_tree_set_string
call.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
<<winmail.dat>>
