Re: Is it still ok to create hidden items ?

[Roland Knall <rknall () gmail com>]

Hi

Ok, always ready to learn something new, but answer me this:

 You have two fields displayed, in my case:

Sender: 0x0001
Receiver: 0x0002

How do you add a generated field, which will match either one of these
entries, so that you can ask:

opensafety.msg.node == 0x0002

and only receive messages where either the Sender or the Receiver
field has the value 0x0002 ?

Using generated fields, just clobbers up the display in such a case,
because you would have to have 2 entries for [Node] which confuses the
user. Or am I overlooking some special usage of generated fields here?

One definite negative side-effect of using hidden fields is of course,
that you can not use the "Apply as .." or "Prepare as .." entries, and
that the user has to know about them. But that was already mentioned
earlier.

regards,
Roland


On Mon, Oct 31, 2011 at 11:03 AM, Anders Broman
<anders.broman () ericsson com> wrote:
> Hi,
> I'd say using a generated field is more elegant :-)
> /Anders
>
> -----Original Message-----
> From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Roland Knall
> Sent: den 31 oktober 2011 10:51
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Is it still ok to create hidden items ?
>
> Hi
>
> As I just came across something regarding this issue, there is a counter argument to the whole "if it is not there, 
> the user may not find it" idea. Looking at the way the IP dissector is used, hidden fields have their merits. ip.addr 
> is a more generic way of avoiding ( ip.src == x || ip.dest == x ). I plan to use it in the same way in the openSAFETY 
> dissector, where I have the fields opensafety.msg.sender and opensafety.msg.receiver, and I am currently implementing 
> a opensafety.msg.node matching either one.
>
> The most elegant solution for such a case is still using hidden fields.
>
> regards,
> Roland
>
> On Thu, Oct 27, 2011 at 4:04 PM, Teto <mattator () gmail com> wrote:
> > Thanks for both of your ideas. What bothers me with Michaels'idea is
> > that I wonder how many wireshark users know of or use "contains" and
> > "matches" compared to eq or == keywords. From that point of view,
> > Jeff's idea looks as a good idea.
> >
> > On Thu, Oct 27, 2011 at 3:34 PM, Jeff Morriss <jeff.morriss.ws () gmail com> wrote:
> > > Teto 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
> > >
> > > Why not combine the two?  Put one item (or maybe even just a text entry--from proto_tree_add_text()) with all the 
> > > keywords (possibly added with proto_tree_append_text()) and then create a subtree below that with each keyword 
> > > individually?
> > >
> > > This is how we get, for example, nice summary lines for the TCP protocol (including port numbers, etc.) while 
> > > keeping the port numbers themselves as separate filterable items in the TCP subtree.
> > ______________________________________________________________________
> > _____ Sent via:    Wireshark-dev mailing list
> > <wireshark-dev () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> >
> > mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe