The very idea of debugging seems to be to check the state of variables. Even in LabVIEW, which technically does not have variables (sure, global variables, which I avoid, functional globals, which I sometimes use, local and shared, which have their right to exist.. sometimes,.. network, yadada, yadda), the probes and breakpoints are designed to look what kind of data is stored.
(Actually, there was quite a good article in the last NI newsletter if you are new to debugging in LV) [Source, p26]
This is okay. I mean, most of the time, it’s okay. I mean, it’s programming, what else should you do?
But the thing is: Sometimes a more visual approach helps. Sometimes, especially in image processing, it helps to see what a user is seeing.
Maybe you want to log the state of a GUI without reading every single element. Maybe you’ve already found a great way to make your data easier to understand . Maybe you want to see a snapshot of a camera stream..
A really cool part of Windows 7, the problem steps recorder (just type psr after pressing the Windows key – try it, it’s neat!) inspired me to add this thing to my error handling/debugging lib.
Basically, you just force Windows to use it’s own “screenshot” hotkey (aka Print on your keyboard), read out the clipboard, and write it to some file.
The dll I’m calling is user32.dll, and the header is void keybd_event(int8_t arg1, int8_t arg2, int32_t arg3, int32_t arg4);
It’s not rocket science, but it’s been useful to me in my last project.
(Btw, I combine this with a small FileName-Generator-vi, which adds DateTime + the name of the caller vi. If I have very high numbers of calls, I write to a Ramdisk, which is the single most greatest thing I’ve learned to use in Windows this year.)
Then I add a conditional code block into every state of my gui state machine, which is activated if screenshot=true. Super-fast handbook, and especially great for unclear, user-reported bugs..