Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.
I would find it real useful to know the time an error code is generated. If "time" were to be grouped into the current standard bundle of "status", "code" and "source" that would be just super.
This sounds like a good idea, but I'd be afraid it would be impossible to implement.
1. Every VI within LabVIEW that could be the source of an error would have to be redefined to include the time part.
2. If it is a change to the error cluster itself (such as putting a 4th element called time) then every VI that has been created that touches error wires, even if it just passes errors through, would need to be changed because of the new datatype.
I think the best you could do would be to implement this yourself in any VI that you create that is a source for errors where you embed the time information within the source string. Just like some VI's include path data and some don't. You could create a subVI that you drop into an error wire after other VI's and functions that could add a timestamp to the source in the event of an error and the timestamp isn't already there.
RavensFan: I actually think the mutation is quite viable. The question is the massive amount of memory that would be allocated -- an extra 128 bytes for every error cluster allocation everywhere -- essentially every individual wire of error cluster type (less because of the inplaceness optimizations but the order of magnitude is right).
We could add that timestamp info as part of the string, but that would probably not suffice since that would not be readily extractable. And we couldn't guarantee it existing across all clusters.
In the meantime you could look at the GPower Error and Warning toolset which has an option for including a timestamp when setting an error or warning. This at least makes it easy to include timestamps when throwing your own errors;
Yes, although the version I reference above is newer than the one on the LV Tools Network. It'll be updated at some point in time, or you could send me a message to get the most recent VIP.
Steen's workaround only works, of course, for errors that you yourself are generating within your code. keithn's idea extends to all errors, I suspect. That's likely a near impossible undertaking. Probably reasonable (if a lot of work) to modify the cluster to be *able* to store timestamp, impossible to get all of the code that generates errors to actually include the timestamp.
> All you have to do is create a new class which extends
> the LV Erorr Class. Oops, sorry I am daydreaming about LV2025 again.
That wouldn't help get every place that can generate an error to do so. You would need to get all places that generate errors to instantiate your new child class. You would need to *replace* the error cluster with a class, hide all the private data so that people can only set the value through a function call and then make this part of the base class functionality to set the timestamp when ever the "Set Values" function is called.
Steen wrote:
> Or plug in this little VI where you want the timestamps to be added :
That works only assuming you even have permission to change the code on the remote system that is sending you errors or in the deep subroutine where the error is being generated. So, as I said, it only helps with errors that you are generating in your code.
Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.