Adding a date to the History section of the Command Window

This would definitely be a good addition. Perhaps there is a hidden way to extract the information from previous experiments. In the meantime, I have this code in a "JJW Core Functions" procedure in my Igor Procedures.

When it is important for you to document what you do at time t in a manner that would be understood at t+dt you may want to consider using an Igor notebook for your work.  You include in the notebook all the details.  You can insert timestamps as jjweimer suggested above and make sure to execute all your commands from the same notebook.  Remember, to execute commands you need to select them in the notebook and type Ctrl-Enter.

Following on the suggestion to run commands from a notebook, the LogBook package allows you to type executable commands into a note field. It runs those commands and assembles the results into a notebook with a date+time stamp. It can also assemble the history log (cumulative or snapshot).

What might be nice is to have a hook function(s) Before/AfterPrinttoHistoryHook. Users could then create their own date+time stamp output (or create one reporting function) using such a hook function.

A not very elegant but workable way to achieve this with the available hook functions could be to use AfterFileOpenHook() and a persistent global variable. The global variable holds the date of the last update. After the experiment was opened, check the global and if the date has changed print a line with the current date, then update the global. This way, the current date would be saved whenever one works on the file.

You can probably do this already with a modification of HistoryCarbonCopy... which I've almost achieved but Hooks/UI aren't my forte so there is a bug. Someone more skilled can probably spot my blunder in the window hook function - the rest is cribbed straight from the manual I think: 

EDIT: I figured out a quick and dirty kluge and fixed where the history would be killed. Unfotunately it won't do anyting for old experiments but you can  use it going forward if it is useful to you. You could also have an IgorStartOrNewHook that just prints the date everytime you open an experiment. The history carbon copy you can at least search and save as text if required.

The HistoryWindowHook function causes Igor to crash because it is modifying the notebook while Igor is in the process of modifying it. We can reproduce the crash by typing in the HistoryCarbonCopy.

I am investigating this, but it looks like, to prevent crashing, we will have to make it an error to call the Notebook operation from a hook modified event (s.eventCode==8).

@hrodstein

That is unfortunate, I don't see a crash, hang or anything untoward FYI.

Even more reason to have a datetime option in the command history - maybe if you hover over a line with your cursor a help bubble could have the information.

For the record: I also did not encounter any crashes while playing around with cpr's code (Win 10, Igor 9 beta). Would it be a solution to push the update into the operation queue? This way the notebook is not updated during the execution of the hook function.

@chozo

I'm also using IP9 under Windows - though 32-bit, for reasons...

Your solution neatly sidesteps the issue hrodstein is worried about without having to ban the call for window modified events entirely - though WM probably wouldn't like to leave any possibility for crashes open as I always seem to find them :-D . In my playing around I investigated using GetRTStackInfo() as I was worried about the call being self refferential, but that yeilded zip.

What I posted was hastily knocked together example of what might be possible now, though I think the original feature request is a good one even if I wouldn't be the target not having saved an experiment that wasn't sent to support since about 2015 due to how I use (abuse) Igor, though I use HistoryCarbonCopy a lot, just not with that hook. 

In my defence I got my excuses in ahead of time!

It crashes for me every time in Igor Pro 9.00B08 on Macintosh and Windows 32-bit and 64-bit. To make it crash, I create the HistoryCarbonCopy window, click at the end of the first line of text, and press return.

I think, even if this didn't crash, the use of the modify event to modify the notebook should create another modify event and so on ad infinitum (cascading modified events).

Would it be a solution to push the update into the operation queue?

Yes.

However, the cascading modified events may still be a problem.

Hooks are useful but can also open up all kinds of bizarre scenarios (e.g., a window hook that kills the window) so it is best to keep it simple.

@hrodstein - you must have the extra special build as I cannot get a crash in 37767 using my original kluge. I will however differe to others undoubtedly better knowledge of hook functions etc.

@cpr I will attach my test experiment. Please let me know if it crashes for you.

1. Open the experiment.

2. Execute "CreateHistoryCarbonCopy()".

3. Click at the end of the first line of text in the notebook.

4. Press Return.

Also please confirm that you are using 9.00B08 on Windows 32-bit.

@hrodstein - Now that does crash nicely...  however that is not the code in my example which explains the discrepency. I changed it to fix a bug... 

We're both right, ballance is restored!

You have demonstrated that it is possible to use the Notebook operation from a modified event without crashing and that it is possible to make Igor crash using the Notebook operation from a modified event.

I'm not sure if there is a solution for the crash short of making it illegal to call the Notebook operation from a modified event. I will continue investigating.

For Igor Pro 9 only, I have change the way notebook modified messages are sent. The change is in the Igor Pro 9 nightly build now available.

Previously notebook modified messages were sent from the internal Igor code that triggered the modification. This could cause a crash if a window hook function modified the notebook because the message was sent before the original modification was complete.

Now (build 37772 or later), the notebook modified event is sent from Igor's outer loop when it is idling (i.e., after procedure execution finishes). This prevents the crash described above. It also means that, if you modify a notebook programmatically, the modified event is not sent to hook functions until Igor returns to idling. Also, modifying a notebook from a notebook modified event does not cause recursion to the window hook.