Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

No changes were made regarding timestamping and file handling. I wanted to get the main options out of the way first before concentrating on that aspect of the program. I'll work on it more later; need some sleep right now.

Since we've decided on the .anu extension, here is how I would like to handle the writing and archiving of logs. If you agree to this, then adding custom timestamp formats for the log files would be a snap to implement. Also, the custom log folder will be easy to implement as well.

1) The current log will be written to the app's folder as "current.anu". Basically, no timestamp on the filename at this point.2) When the archiving routine fires, the "current.anu" will be moved into the archive folder using whatever timestamp format the user has set.3) Collisions will get the "[1]" addition or however you would like that handled.

If the log filename timestamp format includes the time, collisions should rarely happen. Also, I think I'm going to add a button to the Archive tab that will allow the user to initiate the archive routine immediately. Your thoughts?

I was actually going to suggest this exact method of archiving. Glad you anticipated it. Needless to say, I approve.

1. File collisions could be avoided if the filename included the time as well as date. However, I find [1], [2] to be personally acceptable.

2. Right-click option to Archive current log = good thing.

3. An advantage to using current.anu is that when the viewer is invoked, it can easily be programmed to display the most current logfile. Obviously, it should not lock this file when it is being viewed.

4. I see the viewer as a separate .exe from Anuran. From the limited comments in this thread, there are some who want one, some who don't, so a separate viewer would please both crowds.

If you don't mind another of my drawings, here's another mockup of a simpler two-pane viewer layout. (Stick with whatever you feel works best, however):

Notes:0. Proposed viewer names: Anuview, Anuvu, Anuran Viewer1. The panes and window itself would be resizable, of course. 2. The items in the logfile pane would be organized according to file datestamp, or according to the first datestamp contained within the file itself, in case the file properties get messed up by Windows.3. On startup, Anuview defaults to current.anu. Logfile pane defaults to \archive, but the current.anu is always displayed on top.4. If Anuview is started by double-clicking on a .anu file, it displays the file, regardless of where it is, plus any other .anu files that are in the same directory as the .anu file it is displaying. This is for folks who end up moving their logfiles around.5. Do we want a full-on file tree in the logfile pane, or just a 'flat' list of logfiles in \archive?6. Ignore the titlebar and status bar ornamentation, they come from bblean's skinning engine. 7. And yes, I basically took a screenshot of MiniAim, and cut and pasted around.

Blue-sky possibilities:

1. If you apply a 'tail' function to the viewer, it could even auto-update the contents, which provides a fingertip-ready view of the last x hours of entries. I worry a little about people who want to tail their own personal log, but it does provide a quick answer to the question "Now, just what the hell have I been doing the last hour?"

2. An automatic vertical timescale that visually measured the time between each entry would still be a pretty neat Stupid Coding Trick.

1. File collisions could be avoided if the filename included the time as well as date. However, I find [1], [2] to be personally acceptable.2. Right-click option to Archive current log = good thing.3. An advantage to using current.anu is that when the viewer is invoked, it can easily be programmed to display the most current logfile. Obviously, it should not lock this file when it is being viewed.4. I see the viewer as a separate .exe from Anuran. From the limited comments in this thread, there are some who want one, some who don't, so a separate viewer would please both crowds.

1) Correct...putting the time in there, especially with seconds, should avoid any collisions.2) I will add this in the next build (along with customisable archive folder).3) The viewer will never lock the file.4) Hmmm...I'll give this idea some thought.

If you don't mind another of my drawings, here's another mockup of a simpler two-pane viewer layout. (Stick with whatever you feel works best, however):Notes:0. Proposed viewer names: Anuview, Anuvu, Anuran Viewer1. The panes and window itself would be resizable, of course. 2. The items in the logfile pane would be organized according to file datestamp, or according to the first datestamp contained within the file itself, in case the file properties get messed up by Windows.3. On startup, Anuview defaults to current.anu. Logfile pane defaults to \archive, but the current.anu is always displayed on top.4. If Anuview is started by double-clicking on a .anu file, it displays the file, regardless of where it is, plus any other .anu files that are in the same directory as the .anu file it is displaying. This is for folks who end up moving their logfiles around.5. Do we want a full-on file tree in the logfile pane, or just a 'flat' list of logfiles in \archive?6. Ignore the titlebar and status bar ornamentation, they come from bblean's skinning engine. 7. And yes, I basically took a screenshot of MiniAim, and cut and pasted around.

Zero-relative. Hehehe.0) I like AnuVu best. =]1) Agreed.2) Well, pick one. I would prefer to go off of filename, personally.3) Can do.4) Sure.5) Flat list. Trees in AHK are a pain in the arse.6) Yep, I run bbLean as well.7) No worries; this is extremely close to what I had in mind for a simple viewer.

Blue-sky possibilities:1. If you apply a 'tail' function to the viewer, it could even auto-update the contents, which provides a fingertip-ready view of the last x hours of entries. I worry a little about people who want to tail their own personal log, but it does provide a quick answer to the question "Now, just what the hell have I been doing the last hour?"2. An automatic vertical timescale that visually measured the time between each entry would still be a pretty neat Stupid Coding Trick.

1. The download is for the 1.0.1 build. Screenshots are tantalizing, though.

2. I agree that having the viewer sort logfiles according to the timestamp in the filename is best, I was just concerned that if the user can change the filename timestamp to whatever he wants, AnuVu would get confused.

Have people considered using this for basic time-tracking ?e.g. if I always lead my note with say ARD for project #1 & SURV for #2 etc,then if I was able to sort notes alphabetically (& by time) I could roughly see how long I was working on each project

The idea has been in the back of my mind - to be honest I havent really considered it practically beyond what I've written here - just throwing it out there as is

Have people considered using this for basic time-tracking ?e.g. if I always lead my note with say ARD for project #1 & SURV for #2 etc,then if I was able to sort notes alphabetically (& by time) I could roughly see how long I was working on each project

The idea has been in the back of my mind - to be honest I havent really considered it practically beyond what I've written here - just throwing it out there as is

I've actually been having similar thoughts. This idea has always been a very simple time-tracker/personal blotter for me, but it would be interesting to see a script that could:

1. parse out the individual entries and separate them into categories based on the first word in each entry2. Then, it could conceivably 'guess' the amount of time between tasks and types of tasks, by measuring the difference in time between the entries. 3. From there, the data can be measured on a time scale, or with graphs, and so forth.

This is all completely beyond the scope of my original request, of course. I'm very happy with what I have so far. For now, you might actually be able to do something like this with a spreadsheet and a fistful of Anuran logs.

I've actually been having similar thoughts. This idea has always been a very simple time-tracker/personal blotter for me, but it would be interesting to see a script that could:1. parse out the individual entries and separate them into categories based on the first word in each entry2. Then, it could conceivably 'guess' the amount of time between tasks and types of tasks, by measuring the difference in time between the entries. 3. From there, the data can be measured on a time scale, or with graphs, and so forth.

1) This would be easy.2/3) This, currently, would not be easy. If Anuran was to go this route, I would have to take out the custom timestamps to the log files as well as the entries and replace them with a full, standard one. Otherwise, it's conceivable that a user could use a timestamp format that didn't contain all the necessary bits to do this calculation. Does that make sense?

will one be able to search all log files via the viewer ?or would you recommend using another app?

Re: the timetracker idea - one would really have to indicate when you're starting on a project & when ending - otherwise: if all other entries are filtered out you wouldnt know at which times you began / ended

we might be reinventing the wheel with the time-tracker ideaI was just having another look at Skrommel's TaskLog - mind you after doing a search I see I had a problem with hibernation which I use relatively often (my computer has problems with standby)

TaskLogYou define your tasks - it logs amount of time spent on each (asks at user selected intervals)Saves in a csv file, which it can also sort before opening (in Notepad)