OK, that is what I have done.
Different hf_ for display purposes but the same name (mtp3.opc) for
filtering purposes.
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Friday, December 05, 2003 1:20 PM
> To: Jeff Morriss
> Cc: mlum@xxxxxxxxxxxxx; ethereal Development List
> Subject: Re: [Ethereal-dev] Patch to expose OPC/DPC from MTP3, SCCP
> preferences
>
>
>
> On Dec 5, 2003, at 10:43 AM, Jeff Morriss wrote:
>
> > It's been a while since I actually worked on a dissector, but I think
> > it's okay to have 2 hf_ variables that correspond to the same filter
> > string.
>
> Yes, it is. We use that to, for example, handle some fields in X.25,
> as their bitfield masks are different depending on whether you're using
> mod-8 or mod-128 mode.
>
> > E.g. something like:
> >
> >> { & hf_mtp3_itu_opc,
> >> { "OPC", "mtp3.opc", FT_UINT32, BASE_DEC, NULL,
> >> ITU_OPC_MASK,
> >> "", HFILL }},
> >> { & hf_mtp3_ansi_opc,
> >> { "DPC", "mtp3.opc",
>
> (Presumably you meant "OPC", not "DPC".)
>
> >> FT_UINT32, BASE_NONE, NULL, 0x0,
> >> "", HFILL }},
>
> So in that case a particular item in the protocol tree would either be
> associated with hf_mtp3_itu_opc or hf_mtp3_ansi_opc. However, a filter
> expression that contained "mtp3.opc" would work with the item
> regardless of which of those particular hf_ variables was used.