Wireshark-bugs: [Wireshark-bugs] [Bug 11369] "Show packet in new window" resets packet info to T
Jeff Morriss
changed
bug 11369
| What |
Removed |
Added |
| Status |
INCOMPLETE
|
RESOLVED
|
| Resolution |
---
|
FIXED
|
Comment # 6
on bug 11369
from Jeff Morriss
(In reply to arthur.yurov from comment #5)
> If there was no display filter, the header part (I don't know the
> terminology here for the top section) displayed correctly, this was how it
We usually call that the packet list pane. Or talk about the columns. The
(typically middle) pane is the packet details pane while the (typically bottom)
pane is the packet bytes pane.
> We had a few "if (tree)" checks. Removing them and recompiling the plugin
> (still 1.99.3) fixes the entire issue. Filtering, showing packet in new
> window, works perfectly fine in both the Legacy version and new version of
> the UI. So it was actually because of this, which forces me to ask what
> changed that causes "if (tree)" checks to be unnecessary? Are we always
> getting a tree from Wireshark now, and it's never null?
That's funny; I asked out of completeness but normally people with too many
if(tree)'s have the *opposite* problem: that things work when there's a dfilter
but don't work when there isn't. And certainly I wouldn't expect a difference
between the two UIs.
The tree behavior hasn't really changed that I'm aware of. It's NULL on the
first pass and non-NULL on the 2nd (and subsequent) pass(es). Mostly the
if(tree) checks are being deprecated because:
1) they're really only there for efficiency (to avoid unnecessary work during
that first pass)
2) BUT they're a source of a lot of trouble: there's a long list of things you
mustn't do inside an if(tree) check (like updating column text or adding expert
info) and, well, a lot of those things still end up happening inside an
if(tree) check. Even the most experienced Wireshark developers will miss some
of these things so mostly these days we just tell people to take out the
checks.
> And follow-up, are there any resources you can point to that better lists
> and explains these sort of changes?
Well, not really. One advantage of submitting your dissector to Wireshark is
that a lot of these kinds of checks happen before it's committed and any API
changes are dealt with by whoever's changing the API. :-) (There are plenty of
esoteric most-people-will-never-see-the-protocol-in-the-wild dissectors in
Wireshark.)
Anyway, glad you got it working, closing this one.
You are receiving this mail because:
- You are watching all bug changes.
