Wireshark-dev: Re: [Wireshark-dev] Is it still ok to create hidden items ?
From: Teto <mattator@xxxxxxxxx>
Date: Thu, 27 Oct 2011 12:10:52 +0200
seems only logicial. That's what I had guessed but wanted to make sure
in case I plan to upload a patch later on.

thx for the advice.

On Thu, Oct 27, 2011 at 12:06 PM, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> Hi,
>
> I think one of the reasons why one should avoid hidden items is that
> if they dont
> show up in the dissect pane, users might not be aware that they exist at all.
> And then they will not be able to use them.
>
> Wireshark supports so very many different filter fields that it is not
> practical to use a "list of all filterable items".
>
>
> So see it as "if they show up in the dissect pane, this is how you
> tell the users 'these fields exist, you can filter on them'"
> If they dont show up in the disset pane, no one will know about them
> or use them, i.e. they dont exist :-)
>
>
> regards
> ronnie sahlberg
>
>
> On Thu, Oct 27, 2011 at 8:54 PM, Teto <mattator@xxxxxxxxx> wrote:
>> Hi,
>>
>> Just had a question about what's the best practice. I have a packet
>> with a field contianing several keywords. I intend to split those
>> keywords so that one can filter display based upon a keyword.
>> My problem is am compelled to display each keyword separately (one
>> itemp per kewyord and group them in a subtree) or could I display all
>> of them in one item in the main tree (my preference) and then create
>> several hidden fields (one per keyword). I wonder if that last
>> solution is good since I read in proto.h :
>> /* HIDING PROTOCOL FIELDS IS DEPRECATED, IT'S CONSIDERED TO BE BAD GUI
>> DESIGN! */
>>
>> What would you advise me ?
>>
>> Matt
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
>