A simple text search would be easy to implement since each entry is properly delimited with a "§`r`n" sequence.

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

Right...this is where it gets fuzzier since custom timestamps are allowed. Furthermore, I haven't designed Anuran with this in mind. It's not really a time-tracker. It's more of a "what were you doing/thinking/feeling at said time" application. This behaviour is more in line with doctorfrog's original request.

I'm a fan of the "one tool for one job" way of coding. With that in mind, I think there are plenty of time/project trackers out there that do a much better job than anything I could code. Please don't take this as me discounting your suggestions, tomos. I really appreciate the feedback.

Right...this is where it gets fuzzier since custom timestamps are allowed. Furthermore, I haven't designed Anuran with this in mind. It's not really a time-tracker. It's more of a "what were you doing/thinking/feeling at said time" application. This behaviour is more in line with doctorfrog's original request.

I'm a fan of the "one tool for one job" way of coding. With that in mind, I think there are plenty of time/project trackers out there that do a much better job than anything I could code. Please don't take this as me discounting your suggestions, tomos. I really appreciate the feedback.

no worries Skwire - just an idea, I was unsure of it myself & realised it might not be suitable(BTW I like TaskLog a lot but never really used it due to aforementioned problem - so I've bumped that thread)

I've got an idea that I think will make the viewer work well with a search...

1) The left-side listview will have checkboxes for each entry.2) The contents of all checked entries will display in the right-side edit field. Call this the "current view"3) A toolbar will be at the top with buttons for quickly checking/unchecking all entries, etc.4) A search field along the bottom of the listview will allow for find-as-you-type search capability within the "current view" and will then display only the entries that contain the searched string.

Impressive. I wasn't aware that we could take it this far. I like the idea of search more now, because of the possibilities of "log clog." Without some sort of search, there will eventually be so many logfiles that they simply won't have meaning anymore. The app becomes a victim of its own success, as it were. Search helps to stave this off.

Notes:1. When multiple logifles are checked, how will they be displayed in the main viewer? In a chrono-order? Will there be any visual grouping, such that entries from different logfiles are separated somehow?2. Minor suggestion: to keep with the current trend of searchboxes in apps and online sites, move searchbox to upper right corner, in line with the toolbar.3. Consider changing the style of timestamps, such that they are visually separated from entries. My preference: slight reduction in font size, and bolded.4. With search filters in place, my next want will be to "export the current view" to another text or .csv file. At the very least, I should be able to select text in the viewer pane and copy it elsewhere, but more advanced users might want to keep the logfile markup intact for their purposes.5. Quibble: I prefer a white background for the log viewer pane rather than gray. It's consistent with the look and feel of most other apps.6. I already see 'select all' and 'select none' functions are planned. CTRL-CLICK on a checkbox should also toggle the behavior.7. Does the search also respond to dates/times? Obviously, if the user changes his timestamps midstream, he's up his own creek with how consistently this would work.8. Earlier request, repeated: When AnuVu is started by opening a .anu file, it should display the logfile, plus any other logfiles in the same directory. This is for users who end up moving their logfiles around.9. What if a user has logfiles in multiple folders but wants to display them together with AnuVu? This strikes me as a fairly rare use case, so I don't think it's necessary to address it, but I feel it should be mentioned.

1. In filename order with no grouping. This is just a simple edit control so there are limitations to what I can do with it. Some alternatives would be for me to change to the HiEdit control or RichEdit control. Both of these add quite a bit more complexity to the app but I've not ruled them out entirely. FWIW, I enjoy the plain-textedness of apps...including this one.

2. I can put it above the display field but not in line with the menu items. Would that be acceptable?

3. Again, I'm working with a simple edit control. There are no per-line formatting options.

4. You can highlight and copy out of it like any normal edit control.

5. The reason for this is that I've set the edit control to read-only to stave off the impression that you can modify the text. I can take off this property which will turn it back to white. However, any changes made to the text will not be saved.

6. Toggle which behaviour? I'm going to add a right-click menu to the listview in the next build with "Check all" and "Uncheck all" options.

7. It's a simple text match search. If your search string is anywhere within an entry, including the timestamp, it will match.

8. Currently, AnuVu will get the folder that you have configured in Anuran and show the current.anu in that folder along with any .anu files found in the \archive subfolder. I'll change it to display any .anu files in the configured folder as well as the \archive subfolder.

9. I can add drag & drop capabilities to the form. I can also build in a context menu extension so you could right-click a group of .anu files and add them to AnuVu. I've built AnuVu's display and search functions to handle whatever .anu files it has listed in the listview. This is actually much easier to implement than it may sound.

Notes:1. When multiple logifles are checked, how will they be displayed in the main viewer? In a chrono-order? Will there be any visual grouping, such that entries from different logfiles are separated somehow?2. Minor suggestion: to keep with the current trend of searchboxes in apps and online sites, move searchbox to upper right corner, in line with the toolbar.3. Consider changing the style of timestamps, such that they are visually separated from entries. My preference: slight reduction in font size, and bolded.4. With search filters in place, my next want will be to "export the current view" to another text or .csv file. At the very least, I should be able to select text in the viewer pane and copy it elsewhere, but more advanced users might want to keep the logfile markup intact for their purposes.5. Quibble: I prefer a white background for the log viewer pane rather than gray. It's consistent with the look and feel of most other apps.6. I already see 'select all' and 'select none' functions are planned. CTRL-CLICK on a checkbox should also toggle the behavior.7. Does the search also respond to dates/times? Obviously, if the user changes his timestamps midstream, he's up his own creek with how consistently this would work.8. Earlier request, repeated: When AnuVu is started by opening a .anu file, it should display the logfile, plus any other logfiles in the same directory. This is for users who end up moving their logfiles around.9. What if a user has logfiles in multiple folders but wants to display them together with AnuVu? This strikes me as a fairly rare use case, so I don't think it's necessary to address it, but I feel it should be mentioned.

Currently, I have Anuran set to archive my logs every day. This doesn't seem to be happening. Does Anuran only archive every day, only if it's running for 24 hours? Can it check the creation date of the log, and go by that instead?

Example: Anuran is launched. It parses current.anu. If the first entry is older than the 'Archive logs every n minutes/hours/days,' it archives the logfile.

Anuran:1. I had a little confusion with the Archive folder setting. I specified .\archive, which actually put files in .\archive\archive. Consider rewording "Archive folder" to "Anuran log folder (archives will be kept in .\archive)" Wordy, I know.

AnuVu1. Feature request: ability to sort the logfile list pane by date. "Date" column should consider the first entry in a logfile as the date, rather than the file properties (more accurate). This sort should be the default. current.anu should remain on top at all times (current behavior).2. Feature request: refresh button/menu options/hotkey (F5).3. GUI: make current.anu in logfile list pane bold.4. GUI: by default, when AnuVu starts, select and display only current.anu.5. Feature request: in logfile viewer pane, offer option to sort entries by time, oldest to newest, or newest to oldest. If this isn't doable, offer option to start at bottom of logfile on startup, so that newest entries are displayed. May be a moot option if we offer the 'tail' function later on.

Notes:2. Minor suggestion: to keep with the current trend of searchboxes in apps and online sites, move searchbox to upper right corner, in line with the toolbar.6. I already see 'select all' and 'select none' functions are planned. CTRL-CLICK on a checkbox should also toggle the behavior.8. Earlier request, repeated: When AnuVu is started by opening a .anu file, it should display the logfile, plus any other logfiles in the same directory. This is for users who end up moving their logfiles around.

2) I prefer search box where it is - one would probably often open this from systray - mouse moves up naturally to search box - also not taking from actual viewer pane6) +1 (would be nice anyway) [Ctrl+Click in one box would select/deselect all]8] could be very helpful if working from usb stick (dont know if that possible?)

2. I like the search box where it is as well. I wanted to make the display pane as large as possible vertically.6. I'm going to have to disagree on this one since it goes against normal Windows behaviour (ctrl-click multi selects...)8. Can do. I'll change AnuVu to look in the following folders:

1. In filename order with no grouping. This is just a simple edit control so there are limitations to what I can do with it. Some alternatives would be for me to change to the HiEdit control or RichEdit control. Both of these add quite a bit more complexity to the app but I've not ruled them out entirely. FWIW, I enjoy the plain-textedness of apps...including this one.

2. I can put it above the display field but not in line with the menu items. Would that be acceptable?

3. Again, I'm working with a simple edit control. There are no per-line formatting options.

4. You can highlight and copy out of it like any normal edit control.

5. The reason for this is that I've set the edit control to read-only to stave off the impression that you can modify the text. I can take off this property which will turn it back to white. However, any changes made to the text will not be saved.

6. Toggle which behaviour? I'm going to add a right-click menu to the listview in the next build with "Check all" and "Uncheck all" options.

7. It's a simple text match search. If your search string is anywhere within an entry, including the timestamp, it will match.

8. Currently, AnuVu will get the folder that you have configured in Anuran and show the current.anu in that folder along with any .anu files found in the \archive subfolder. I'll change it to display any .anu files in the configured folder as well as the \archive subfolder.

9. I can add drag & drop capabilities to the form. I can also build in a context menu extension so you could right-click a group of .anu files and add them to AnuVu. I've built AnuVu's display and search functions to handle whatever .anu files it has listed in the listview. This is actually much easier to implement than it may sound.

1. I still prefer a white background; it's consistent with other apps, and more legible. I am staunchly against RichEdit controls. I can accept the odd 'fake-edit' behavior, mainly because this is a file viewer, not a file editor, and there should not be an expectation for editing features. Purely my preference, feel free to overrule. Tomos, please chime in as well. 2. If you can fit it in line with a toolbar with buttons, it will still look good. Otherwise, keep it where it is. The fact that it's resizable and multi-lined also adds weight to this.3. I'm sad. Can we mark the timestamp lines with brackets or parens to make them visually stand out? This isn't too out of line with other apps that use timestamps, such as Pidgin.5. See #1. Consistency and visibility trumps the concern for me here, but feel free to overrule.6. I mean, toggle the select-all/select-none ability. The right-click solution you outline is fine.7. Cool.8. Sounds good.9. Hey, if you can pull it off, let's do it. This would certainly solve the rare issue I describe. Keeping in line with simplicity and portability, any Windows file system context menu changes should be off by default, and easy to enable/disable.

Aside: I'm idling in IRC freenode/#bb4win if you want to chat directly.

Currently, I have Anuran set to archive my logs every day. This doesn't seem to be happening. Does Anuran only archive every day, only if it's running for 24 hours? Can it check the creation date of the log, and go by that instead?

Correct, Anuran assumes it will be kept running and archives on a running timer. This can be changed how you desire but I'll need to do some thinking on the most effective way. The custom timestamping is what makes something like this difficult. I think the best way would be to keep might be to keep the last archive time in the config.ini and base archive decisions off of that.

1. I had a little confusion with the Archive folder setting. I specified .\archive, which actually put files in .\archive\archive. Consider rewording "Archive folder" to "Anuran log folder (archives will be kept in .\archive)" Wordy, I know.

1. Feature request: ability to sort the logfile list pane by date. "Date" column should consider the first entry in a logfile as the date, rather than the file properties (more accurate). This sort should be the default. current.anu should remain on top at all times (current behavior).2. Feature request: refresh button/menu options/hotkey (F5).3. GUI: make current.anu in logfile list pane bold.4. GUI: by default, when AnuVu starts, select and display only current.anu.5. Feature request: in logfile viewer pane, offer option to sort entries by time, oldest to newest, or newest to oldest. If this isn't doable, offer option to start at bottom of logfile on startup, so that newest entries are displayed. May be a moot option if we offer the 'tail' function later on.

1. What if a user, say, doesn't even use a timestamp? I'm sure you can see the conundrum I'm in with the custom timestamps.2. Can do...I'll make it part of the right-click menu as well.3. I'll see what I can do.4. Okay.5. I'll put this on the ToDo.

1. I still prefer a white background; it's consistent with other apps, and more legible. I am staunchly against RichEdit controls. I can accept the odd 'fake-edit' behavior, mainly because this is a file viewer, not a file editor, and there should not be an expectation for editing features. Purely my preference, feel free to overrule. Tomos, please chime in as well. 2. If you can fit it in line with a toolbar with buttons, it will still look good. Otherwise, keep it where it is. The fact that it's resizable and multi-lined also adds weight to this.3. I'm sad. Can we mark the timestamp lines with brackets or parens to make them visually stand out? This isn't too out of line with other apps that use timestamps, such as Pidgin.5. See #1. Consistency and visibility trumps the concern for me here, but feel free to overrule.6. I mean, toggle the select-all/select-none ability. The right-click solution you outline is fine.7. Cool.8. Sounds good.9. Hey, if you can pull it off, let's do it. This would certainly solve the rare issue I describe. Keeping in line with simplicity and portability, any Windows file system context menu changes should be off by default, and easy to enable/disable.

Currently, I have Anuran set to archive my logs every day. This doesn't seem to be happening. Does Anuran only archive every day, only if it's running for 24 hours? Can it check the creation date of the log, and go by that instead?

Correct, Anuran assumes it will be kept running and archives on a running timer. This can be changed how you desire but I'll need to do some thinking on the most effective way. The custom timestamping is what makes something like this difficult. I think the best way would be to keep might be to keep the last archive time in the config.ini and base archive decisions off of that.

We could resolve this by having Anuran place a generically-formatted timestamp in the first (or last) line of every logfile. It could use this instead of parsing whatever custom timestamp a user might choose. This would also resolve any issues with sorting. If the generic timestamp is missing, AnuVu can just go by whatever's easiest to code: file properties?

just passing through here so have only glanced at previous postsPersonally I wouuld have kept all time stamps (or at least the logfile name/timestamp) as 2009-11-11 21:00or something comparable e.g. 2009_11_11-2100to avoid the : & spaces in the filename -I know Skwire you say some people have a problem with 24hr clock but I think everyone understands it & it sorts logically

6. Concern: My one discomfort now is that, before we had text files being generated that could be human-read with ease. Now, because of the "SS" symbols in the logfile markup, using the viewer is every so slightly forced upon the user, since this is the prime location for a clean view of logs. It's not too bad now, and may be unavoidable, but I suggest we remain cognizant of this, as one of my goals was to keep the logfiles human-readable through the ages, if the user forgets or loses Anuran, or the program itself becomes incompatible with future OS's. Thoughts?

7. Request (maybe maybe): With 6 in mind, offer an easy way to select all text files in the logfile pane and export as "pretty" text, as it would be displayed in the logviewer pane. Result: each individual logfile is translated into a pretty text file. (This is a fairly big maybe.)

8. Bug (keepin' this alive): Anuran only archives a logfile if the user-specified time increment passes while Anuran is running. Solution: base the archive increment on the creation time of current.anu.

Other:- I like how the entries are indented slightly. This is a Good Thing.- I like how AnuVu presents log files. We're moving in a very good direction. With Anuran, we have a means of generating scads of user data. A searchable viewer gives that data a lot more meaning and use. It's a more crucial element than I thought it would be at first, and I'm glad you're working on it.- Your thoughts on my 'generic timestamp' suggestion above? (http://www.donationc....msg184295#msg184295)

1-4. All good suggestions and added to my ToDo. I also plan to add user-configurable font choice.

5. The edit control has a standard menu of its own. How about if I add the Export entry to the File menu? That's where it typically is for most apps.

6. It's a liberty that I almost had no choice but to take; it makes thing much easier for me. I tried to keep it very simple though with only the section (§) marker to denote entries. If it ever came down to it through the ages, a simple search & replace would fix that in no time.

7. To clarify, you want each logfile exported to a separate text file, right?

8. It's on my buglist and should be squashed soon. Here's my logic flow: * Keep track of the last archived time in the config.ini. * On Anuran startup, compare that timestamp with the current time. * If the interval exceeds the configured interval, archive immediately and update config.ini. * From this point, archive on the configured interval timer.

Other:- I like how the entries are indented slightly. This is a Good Thing.- I like how AnuVu presents log files. We're moving in a very good direction. With Anuran, we have a means of generating scads of user data. A searchable viewer gives that data a lot more meaning and use. It's a more crucial element than I thought it would be at first, and I'm glad you're working on it.- Your thoughts on my 'generic timestamp' suggestion above? (http://www.donationc....msg184295#msg184295)

Yes...I try not to lose sight of KISS (Keep It Simple Stupid) when writing an application. Keep it tightly focused but still elegant and useful. I think I address the 'generic timestamp' issue when explaining point #8 above.

7. Good question. The option I had in mind was something like "Export all selected logfiles to individual text files." Kinda wordy. Might need an intermediary dialog... ok, menu option: "Export all..." This leads to a dialog asking for an export location. We can have the full wording there, and a file/directory select widget.People who only want to export the current view can do so via another menu option: "Export current view...", or simply copy and paste the contents of the view pane.

8. That works. Though I still think storing a creation date in each logfile has its uses, particularly for more accurate file sorting (that isn't based on filename or file properties, both of which can vary). Actually, why not pair that with an "archived on" datestamp that appears at the end of the logfile as well?

Other thoughts for myself:- at some point, we'll need to document that .anu files are just text files. The .anu extension and the need for a viewer might lead to the impression that there's some wonky proprietary format at work here.- I might want to write up a basic readme.txt. No need for a full-blown helpfile, though.