Michael Mann
changed
bug 5703
| What |
Removed |
Added |
| CC |
|
mmann78@netscape.net
|
| See Also |
|
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6099
|
Comment # 2
on bug 5703
from Michael Mann
The issue is that "frame data" color_filter isn't populating on the "first
pass", so the hf_ item representing the coloring rule name aren't being called.
As a test, I forced values into the hf_ items for frame.coloring_rule.string
and
frame.coloring_rule.name and they showed up in the column data.
So is this as simple as providing the color_filter data in the "frame data" on
the first pass? I'm less concerned about a performance hit, but more the
architectural ramifications. The packet dissection is independent of the "GUI"
that cares about the coloring, but its the "GUI input" that is causing the
generated fields on future passes over the packets.
Would providing the color_filter data as part of basic dissection be part of
the solution to bug 5158 (color coding in tshark)?
You are receiving this mail because:
- You are the assignee for the bug.
- You are watching all bug changes.
