Hi Gian,
I would not try encoding a pointer into your frame data, but I would recommend including and index, and storing the underlying data in a std::map or similar that’s a member of the results class.
Note that the worker thread which you will push data into the collection is running on a different thread at the same time the generate bubble text function is running on another thread. Be sure to use appropriate thread safety. Also Note that in the current software, an instance of your analyzer might get used multiple times for re-analyzing the same capture, so the first thing you should do in the worker thread is reset your collection, in case it contains data from a previous run.
In general, the idea for FrameV1 (just called Frame in code) is that you would “pack” the pertinent data into mData1, mData2, mType, and the other members. This was for several purposes:
- speed up the worker thread by avoiding string interpolation code.
- reduce memory usage by just storing the pertinent information, and not mostly static string data.
In your case, we would recommend packing nReset into mData1, then you would unpack it and generate a string in the get bubble text function. You really shouldn’t use external storage until after you’ve run out of space in mData1 or mData2.
You can see how we do this for our I2C analyzer here:
In retrospect, this was not the best solution. We designed this way back in 2009, I believe, and we have tried to avoid making breaking changes to the API to keep backwards compatibility simple and avoid breaking existing analyzers. However we do want to eventually overhaul this API with something much easier to use.