LabVIEW
Best practice on How to deal with a big "Status string box"
Hi,
For my application I have an "Upload to DUT" operation to do which uploads either software images or parameters (all separated in chunks) to my device.
So far so good (still a work in progress but it's ok) but I was questioning myself on how to handle best my "status box" which can be reviewed during operations and saved when it's finished.
For each chunks, I am creating a string showing the chunk, it's data, and the status result (Ok - no error; Error; Timeout; etc.) whcih I add to a big string, which is updated every 25 entries (or right away when an error occurs)
For uploading parameters, it's no big deal, about 100 parameters, it's done fast and easy. But for software images, it can go up to about 20k chunks. And even though I've witnessed that this can be handled ok, I'm thinking that this is probably not the best way of doing it.
Instead I only see two different options
- Save it directly to a file instead
- Not sure how that would solve the big data handling problem
- Don't necessary want to keep the file later on, that requires more annoying file handling etc.
- Created an array of strings, and display only a certain amount of indexes based on the "Scroll position" of the status box.
- There is still a big array in the background (of about 20k lines of 2 strings or more) but I suppose this is better to handle a ~100 lines of string on the UI and more, not displayed in the background?
Thanks for your input.
For reference, here is an idea of my window:
Do you actually have a problem with the control showing 20k entries? I've never tried one that big before myself, but I'm often surprised. Say each chunk displays 100 characters; that's 20k * 100 = 2,000,000 bytes, which is a lot but isn't THAT enormous. Maybe the string control can handle it. If so, then I'd just do the simple thing and keep it as-is. A string variable (i.e., wire) can have up to 4,294,967,295 characters in it so you have some headroom there 🙂
If it doesn't work well/is confusing/etc, then I think I'd recommend streaming the data to a file AND displaying the last n entries in the display. Stream the data to a temporary file somewhere on disk. If the user wishes to Save the data, then just move that temp file to the Save location the user chose. If they do not wish to save the data, delete the temp file.
By the way, the excellent QControls toolkit has a few examples in it, one of which is the StatusHistory QControl (http://qcontrolsqsi.blogspot.com/2017/05/statushistory-qcontrol.html).
You can set a History length and you can call a method to add a line to the History. The examples show the items fading, but you don't have to do that. If you used one of these you wouldn't need to code up the "keep last n items" part yourself. By setting the history to something reasonable (say, 1000), and streaming all of the entries to a file as mentioned above, you wouldn't need to handle different use cases between "small" runs and "large" runs. A "Small" run wouldn't hit the history limit so it would show everything to the user, and the Large run would only display recent stuff.
If you're comfortable with OOP and are willing to learn a new toolkit (which I100% recommend), you could even combine the file streaming and the display into a single QControl. Overriding Add Item would let you send it to the file at the same time as your display, and you could add a new method to Save the file (that is, move it from a temp location to somewhere good) and a method to delete the file. You can even put the Delete in the cleanup VI so if you forget to delete it it'll automatically get deleted.
Last, if you didn't know about it, you can use Generate Temporary File Path.vi to get a path to the sytem temp directory for saving your temp file. That way, later system cleanups that clear the temp directory will catch any file you forgot to delete.
@VinnyAstro wrote:
I've just tried the example given. Interestingly, if you start asking to add "too much" entries, it becomes very slow even if there are not much entries yet! I've tried with 1000, there were not 10 lines yet that it was going at a rate close to 2s per input..
Interesting. I haven't tried it with more than a couple dozen entries. It's likely adding the strings one at a time, and it's also probably reformatting the whole string (since it does the "fade out" thing). If it seems useful to you, you could dig into the Event Handler and see if you can find what's taking so long, or you could post on the Enthusiasts forum about it (https://forums.ni.com/t5/QControl-Enthusiasts/bd-p/5383) and see if the original dev can comment on why it might take so long
Without looking into it I bet it's the formatting. Updating it to either 1- don't reformat if the "old" and "new" colors are the same, or 2- only apply formatting to the newest entries (that may not be possible, as I'm not super familiar with string control formatting).
Either way, this approach would encapsulate a lot of what you're trying to do, so if you end up making your own from scratch I'd recommend using the QControl toolkit anyway since it might save you some time.
@BertMcMahan wrote:
@VinnyAstro wrote:
I've just tried the example given. Interestingly, if you start asking to add "too much" entries, it becomes very slow even if there are not much entries yet! I've tried with 1000, there were not 10 lines yet that it was going at a rate close to 2s per input..Interesting. I haven't tried it with more than a couple dozen entries. It's likely adding the strings one at a time, and it's also probably reformatting the whole string (since it does the "fade out" thing). If it seems useful to you, you could dig into the Event Handler and see if you can find what's taking so long, or you could post on the Enthusiasts forum about it (https://forums.ni.com/t5/QControl-Enthusiasts/bd-p/5383) and see if the original dev can comment on why it might take so long
Without looking into it I bet it's the formatting. Updating it to either 1- don't reformat if the "old" and "new" colors are the same, or 2- only apply formatting to the newest entries (that may not be possible, as I'm not super familiar with string control formatting).
Either way, this approach would encapsulate a lot of what you're trying to do, so if you end up making your own from scratch I'd recommend using the QControl toolkit anyway since it might save you some time.
I'm the original programmer on that StatusHistory QControl. It was definitely created for smaller numbers of items and as a visual effect for running a wizard (it is used in the QControl creation wizard), so it wasn't built for speed. However, you could definitely use it as a start for what you want. Create your own QControl from the wizard or feel free to rename and modify the StatusHistory one.
Sound like what you really want is some sort of lazy-loading string. You could use a separate scrollbar control in conjunction with a string. Then create a buffer for your string through an array or queue. This way you use the scrollbar to define the visible chunk of the buffer to display by indexing the data and passing it as the value to the string. This can still be done as a QControl but you might want to look at some of the other examples to see how to handle multiple controls in one QControl. I do it by either clustering the controls (see Calendar QControl) or by modifying the constructor to have another reference input (see RichTextBox QControl). The clustering method lets you control many more controls without adding a lot of inputs to the constructor, but then you would lose being able to use all of the built-in properties and methods for a string. In your case the RichTextBox example might help.
PS. To @BertMcMahan, you can add formatting to parts of strings. See how I do it in the RichTextBox QControl.
