Wireshark mailing list archives
Re: Is it still ok to create hidden items ?
From: Roland Knall <rknall () gmail com>
Date: Mon, 31 Oct 2011 10:50:32 +0100
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 lastWhy 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
Current thread:
- Is it still ok to create hidden items ? Teto (Oct 27)
- Re: Is it still ok to create hidden items ? ronnie sahlberg (Oct 27)
- Re: Is it still ok to create hidden items ? Teto (Oct 27)
- Re: Is it still ok to create hidden items ? Speck Michael EHWG AVL/GAE (Oct 27)
- Re: Is it still ok to create hidden items ? Jeff Morriss (Oct 27)
- Re: Is it still ok to create hidden items ? Teto (Oct 27)
- Re: Is it still ok to create hidden items ? Roland Knall (Oct 31)
- Re: Is it still ok to create hidden items ? Anders Broman (Oct 31)
- Re: Is it still ok to create hidden items ? Roland Knall (Oct 31)
- Re: Is it still ok to create hidden items ? ronnie sahlberg (Oct 31)
- Re: Is it still ok to create hidden items ? Teto (Oct 27)
- Re: Is it still ok to create hidden items ? ronnie sahlberg (Oct 27)