On Sat, Sep 20, 2003 at 11:04:49AM +0200, Matthijs Melchior wrote:MATCH_NONE, MATCH_TOUCHED, MATCH_TRUE, MATCH_FALSE
Yes, I have been experimenting with an enum added to field_info and
using that to set the background color of protocol tree item.
What are the values of the enum?
I.e., it presumably means you can tag fields as more than just errors;
what other tags can be applied? (Or is it an enum with two values now -
"OK" and "Error" - and the possibility of adding more values?)
In my current code, only MATCH_TOUCHED is implemented. That is set when the value of field is read, and if that field is not visible then an attempt is made to find a visible field describing the same first byte. I am still thinking how to implement the other values, how to associate the result of a test with an actual field, and how to mark a field that was just tested for its presence.
This color
is also applied to all enclosing pdu's in order to notice the presence
of a property without having to expand all sublevels.
By "enclosing PDUs" do you mean the protocol layers above the one that got the error? Or did you mean "enclosing protocol tree items"?
Yes, that is what I mean, the recursive display code will apply the color on its way back up to the parent items of a leaf with color.
This enum is to be set based on the outcome of the packet selection
expression and your proposal would be implemented using the following:
"tcp.checksum_bad == 1 || frame".
Why "|| frame"? That's true of every packet, so that expression always evaluates to "true", right?
Yes, this is a trick to select all packets, and not just the ones with an incorrect checksum. When indicating the bad checksum with a color, this is what you want, it gives an indication about the error rate.
Yes, we need to think about this much more....
Olivier suggested a Boolean for a field that's independent of its value, so that you could have, for example, a bogus packet type value, or an incorrect length field, or... marked as an error; an incorrect checksum would also be so marked.
If we did that, we should probably have a display-filter expression that
evaluates to "true" if a packet contains a field marked as "bad"; with
that, the protocol tree item colorization filter expression could be
just "error" (or something such as that). That'd also let you filter
for bad packets, and find bad packets with "Find Frame".
When thinking about how to continue with this, the following occured to me:
The 3 instances of the color selection dialogue together with the font selction dialogue could be combinded in one style-selection dialogue. And everything that is displayed on the screen will use some style to do so. This style would contain 3 colors [field background, text background and text foreground] and a font. The colorize display dialogue would associate a style with an expression, the TCP Streams dialogue would associate a different style for each party in the conversation, a marked frame would use a style, the hex display would use two styles and some new stuff or just the selection expressions with embedded color directives would provide style info for protocol tree items.
Of course, this is quite a bit of work, designing and implementing...
And, having these styles would ease further developement of the colorization of the protocol tree items....
-- Regards, ---------------------------------------------------------------- -o) Matthijs Melchior Maarssen /\\ [EMAIL PROTECTED] Netherlands _\_v ---------------------------------------------------------------- ----
