Hi, goodmorning, I want to display a bubble text geneated by analyzer, but using Frame is not possible, FrameV2 is only a bridge for HLA, is it right? Extending Frame it’s not working too. The only workaround I found is the following:
Basically I use mData2 as a container of memory pointer, in this way I can use Frame to transport custom data objects around the library.
Is it possible to natively insert in Frame a generic pointer to use as general purpose?
Are there other solutions I don’t have found in the documentation (seams the documentation is not well alligned with the library)?
In any case, congratulations for the analyzer, I have been using it for years.
@gmgunderground With regards to your question about Frame vs FrameV2, we wrote up a support article that hopefully explains the difference between the two.
In short, the FrameV2 class does not replace the Frame class, since the Frame class is still exclusively used to produce the displayed bubbles, and for the analyzer-specific export feature.
There is an example provided in the support article above for managing frames using mData1 and mData2, along with displaying the bubbles with text above your waveform.
Yes I have read the article, but using only type and flag is not much flexible to produce bubbles.
I think having a general purpose pointer inside the Frame class can help very much. Is it a doable update?
@gmgunderground Sorry that didn’t help. We just returned from the weekend, however, I’ll need to pull in our software team to review your use case and we’ll get back to you on this once I’ve had a chance to do so.
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.