That is actually how it is intended. There is no real "finish" to tapdata. Basically you show every data point you wanna show when draw is called, but be aware, that that call may be coming out-of-sync with the overall capture (e.g. not at the same moment new data arrives, therefore data must be thread-safe). Personally I used round-buffers and static memory to avoid having to free memory at the end of it, but I can see how this may become an issue.
cheers,
Roland
Hi,
> WiresharkDialog::registerTapListener() didn't get the finish callback.
> Is there a mechanism for tapDraw() to know that a tap/retap is still
> running?
>
> 'Add a tap "finish" callback, called when a listener is removed.'
If I remember it correctly, finish call back was added to my request
- to allow the code to free memory at the end of capture.
Later I found that it works fine when "static" capture analysis are
running - you work with previously captured file. When you analyze
"running" capture, it is called when capture is terminated. Till this
point capture and tapping is still running even no new data are arriving.
Therefore I never used finish callback :-(
I think that tap listener API is designed for never ending capture by
design and it is good. So later I understood that draw() should expect
that every it's call is the last one and show data that way - e.g.
update statistics, average calculations etc. on every call for data from
start to "now". If it was intermediate call, data will be updated by
later call...
Best regards,
Jirka
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe