Hi,
I'm going by the comment Lars made, which mirrors proto.h:451
/** Add a hidden item to a proto_tree.
@deprecated use proto_tree_add_item() and a subsequent call to
PROTO_ITEM_SET_HIDDEN() instead */
extern proto_item *
proto_tree_add_item_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb,
gint start, gint length, gboolean little_endian);
I presume you are talking about what is said in
http://wiki.ethereal.com/Development/DeprecatedFunctions, where it
suggests using generated fields as an alternative to hidden fields. I
don't know why the above sequence is now recommended - perhaps it makes
people think harder about whether they really want a hidden field?
However, I'm trying to argue that in this case having a hidden field is
justified and shouldn't be visible. Several sip.auth.* fields appear
under 4 different sip header fields (sip.Authorization,
sip.Proxy-Authenticate, sip.Proxy-Authorization and
sip.WWW-Authenticate). I think its illogical not to have a parent
sip.auth field also match against any of 4 concrete headers/containers.
See also these arguments
(http://www.ethereal.com/lists/ethereal-dev/200603/msg00484.html) I
wrote on Friday.
Best regards,
Martin
Jaap Keuter wrote:
Hi,
You missed the point here. proto_add_item_hidden() is no more than the
sequence you coded. The Wiki states to use PROTO_ITEM_SET_GENERATED(item);
This will present the item in the display but in square brackets. See IP
header checksum for a good example.
Thanx,
Jaap
On Mon, 27 Mar 2006, Martin Mathieson wrote:
This is a modified version of the patch I sent on Friday, this time not
using the deprecated proto_add_item_hidden().
I notice that there are still a few uses of it in the tree, is it worth
removing these? The worst offender is (my) packet-ms-mms.c, I can fix
that up soon.
Regards,
Martin
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev