Added history combo to 'Title' field of transform, print/preview dialogs

Added drag'n'drop support for re-ordering tabs

Added optional confirmation dialog to time tracking

Added close buttons to tasklist tabs

Added blank line to single-selection droplists

And much, much more.

Introduction

You know how it is - you start work on one project and halfway through, you find one or two side-projects crop up that have to be solved before you can continue on the original project.

This is one such project with the added twist that it too started its life as a side-project. Here's what happened:

<Cue wavy screen effect>

I can only imagine that the planets must have been in (mis-)alignment or something, because at one point a few months ago, I was suddenly fielding emails on four or five separate articles I had previously submitted to CodeProject, some asking for features and others for bug fixes.

Foolishly or otherwise, I largely agreed with all the points raised, and subsequently found myself with fourteen or fifteen separate issues to resolve.

The situation was also made worse because I was trying to use CodeProject to keep track of all the things I had agreed to do, meaning that I had to continuously trawl the comments section of each article to remind myself of what I was supposed to be working on.

It even got to the stage where I was worrying that I'd fail to deliver on something - silly I know, but there you are!

Keeping a list on paper was a definite step in the right direction, but since I do all my coding on the same machine, it seemed somewhat inelegant, and anyway, we all know what happens to crucial bits of paper left lying around on desks and such.

The next step was to hunt around on the web for a tool to meet the following requirements:

Simple interface

Support for hierarchical data

Numbered items/subitems

Open file format

Freeware

Simple, huh! not!

I will admit that I did not spend weeks searching, but I am still surprised at the general lack of software matching my needs.

On reflection, I think that the reason may be simple: people are so used to commercial software being 'feature-rich' that when they come to design software themselves, they (not unreasonably) think they too need to cram as much in as possible, often leading to software where a lot of essential functionality is hidden away in the menu bar.

So, surprise, surprise, I decided to write something myself.

However, it's fair to say that I did not originally intend to post it on CodeProject and am only really doing so because I had a heap of fun solving some very interesting problems and these are what I think make it worth it.

Using the Software

There's really very little I need to say here since every feature/function is explicitly visible in the interface.

Nevertheless, the following list of basic capabilities and omissions may go someway to answering any questions that arise:

Files are stored in XML format with .xml file extension.

Trying to load a non-tasklist file will generally fail (unless you read the code to see how to circumvent it).

The number of items/subitems is limited only by memory (although performance may be the deciding factor before you exhaust memory).

Marking a parent item as 'done' will also gray-out child items, but they are not disabled or automatically marked as 'done'.

An ellipsis (...) indicates that an item has sub-items.

All items can be expanded or collapsed (by double-clicking).

Top-level items and sub-items are created using different toolbar buttons.

There are task-specific context-menus.

The previously open tasklists are re-opened on startup.

The tasklist is automatically saved when closing the software or minimizing it to the system tray.

The priority of a task is shown as a grayscale box to the left of the item.

Points of Interest

Here's where we come to the side-projects I was talking about, the first two of which I intend to work up into follow-up articles.

They are:

The 'ordered' tree control, which incorporates a non-client gutter for displaying the item numbers.

The idea stemmed from research I did into alternative designs for a tree-list control, which did not solve it by creating a hybrid control incorporating a tree and a list.

The hybrid control seems such an obvious solution that I suspect few people have stopped to question it, but it has still always struck me as looking far too much like hard work to be truly elegant ('square pegs' and 'round holes' spring to mind).

One possible idea is to implement the 'list' portion entirely in the non-client area of the tree. I.e., shift the right hand client edge to the left and then render the list portion in the resulting non-client area.

Whilst I've yet to get round to building a proof of concept, it was nevertheless this ongoing mental debate which prompted me to try to solve the requirement for numbered items and subitems by rendering the item/subitem numbers in the non-client area.

Without going into too much detail (as this will subsequently be an article of its own), this is how I got it to work:

Handle TVM_INSERTITEM and TVM_DELETEITEM to know exactly when items are added and removed.

In these handlers recalculate the width of the gutter required to display the widest 'dotted' item/subitem number. (Note: this is not necessarily simply the deepest subitem.)

Handle WM_NCCALCSIZE when it does, and offset the left border by the required gutter width.

Handle WM_NCPAINT for painting the numbers.

This is necessarily an over-simplification, but it captures the essence of the solution, and all that essentially remains is lots of fiddling about to ensure the non-client area gets redrawn at the the right times to stay synchronized with the client area.

Embedding .RC control definition data directly in a .cpp file to break the dependency on binary resources (a.k.a. 'Runtime Dialogs').

This is an idea that has been floating about for quite some time and which has only recently gelled into a workable solution.

The problem, put simply, is that if you want to take advantage of the resource editor in Visual Studio (and who doesn't), then you very quickly find yourself stuck with having to load dialog templates from resources compiled into the binary file.

This further means that if you want to make use of a dialog across multiple projects, then either you need to copy and paste the dialog template between project .RC files, or you need to build the dialog into a DLL from which it can be accessed.

'Runtime Dialogs' (a snappy title I coined myself) is a solution that neatly sidesteps both the nuisance of copying dialog resources between resource files and the extra work (and maintenance) involved in packaging dialogs in DLLs.

And it works like this:

First, you design your dialog template in the resource editor, create a CDialog derived class using class wizard, and wire up all the controls just as you normally would.

Next, you #include "runtimedlg.h" and change all instances of CDialog to CRuntimeDlg.

Then, you cut and paste the control definition section from the appropriate section in the .RC file and embed it directly in the dialog's .cpp file as a static string (with a bit of tweaking to handle double quotes and such like).

Finally, in the constructor of your dialog, you simply call CRuntimeDlg::AddRCControls(...) passing the control definitions as a string.

And CRuntimeDlg takes care of the rest including, if required, auto-sizing the dialog to suit the control layout.

I'm certainly not suggesting that this is a 'win-win' solution for all situations but it certainly has merits in its closer coupling of dialog template to dialog code which makes sharing dialogs across multiple projects a breeze.

P.S.: In case it's not clear here, I used CRuntimeDlg to create CToDoCtrl which encapsulates the ordered tree together with the priority, date and comments controls as a single simple-to-instantiate control.

This is possibly the most satisfying aspect of the whole project because it was completely unexpected.

What I mean is that, until recently, my knowledge of DOM and XMLDOM was virtually non-existent, as it's only since I've become more interested in the presentation of AbstractSpoon that I've been forced to get to grips with the various implementations of DOM and XMLDOM out there.

I'm pleased to say that the code on my site works under IE 6.0, Netscape 7.1, and Mozilla, although custom code was required to achieve this.

Generic MFC Classes that may prove Useful to You

The following table lists a wide range of utility classes written for this project. They can all be included in any MFC project provided you include any class dependencies too. Feel free to ask any questions relating to these specific classes and how to use them.

Adds support for recognizing urls, clicking them and setting custom url callbacks

CWinClasses

Encapsulates the ::GetClassName Win32 functions

CXmlFile, CXmlItem

Non-Unicode class for reading and writing xml files

CXmlFileEx

Adds encryption capabilities to CXmlFile

CXmlFile, IEncryption

* CSubclassWnd was originally written by Paul DiLascia for MSJ magazine. The version I use has been heavily extended to suit my specific needs. The classes that depend on it here need this extended version.

Further Work

Whilst this tool was originally intended for my personal use only, it is now a 'community' project, so if you find it useful and want to make suggestions for enhancements or bug fixes, then post below.

This is an addition to the original thread http://www.codeproject.com/Messages/4994408/Re-Time-spent-control-bug-v.aspx[^]
I just downloaded v6.9.5, made a test run on English Win8.1/64 with Russian interface, the situation is the following:
1. Fixed incorrect handling of 'C, V, X'
Indeed everything is ok.
2. Fixed 'TimeEst/Spent' keyboard shortcuts to use translated text
I opened an Introduction.tdl on the configuration I mentioned before just from the scratch, still instead of '3' and '4' digits shortcuts for changing daily and yearly display are enabled, so the problem is still there and it's Russian language-related.

I will download the update, but in the mean time I used Wireshark to look at the communication and it looks OK.
There is a Get /todolist_update_new.txt
and then i get a response: 200 OK which has the data
SCRIPT_HEADER: ToDoList AbstractSpoon
SCRIPT_VERSION: 1
EXE_VERSION: 6.86999.104
DESCRIPTION: Fixed rendering of compleded and reference tasks in Find Tasks dialog...(There is more but...)
DISPLAY_VERSION: 6.9.rc4

So what I can understand is the communication working so there must be something else going wrong!

The problem is UAC (That's unusual, isn't it), and probably my configuration.
If I run ToDoList as Administrator then the update works, although there isn't one at the moment.
But if I run it like a normal user then it hasn't rights to write to the C:\Users\\AppData\Local\Temp\ directory.

A bit strange since TDLUpdate.exe is set to run as admin...

Ok, now that I know the problem I can move on and USE your very good program!

Will try to later this evening.
I am only partially following the conversation, but I can save a file directly to the temp folder under my user location. I assume this is the one in question:
C:\Documents and Settings\##me##\Local Settings\Application Data\Temp

We discussed this in-depth a few months ago. I don't have TDL set to run as Administrator, it auto-starts from Programs>Startup, and it does ask for UAC approval on update. I believe if I start manually from a desktop shortcut that is set to run as admin, or if I manually run that as admin, then it does not prompt for UAC.

All that said, @Dan.G, I updated to 6.9.5 and Help>About shows 6.9.5, but if I do a check for updates it shows me 6.9.5 is available for download and asks if I want to update.

To address this ongoing user uncertainty factor, it might be helpful to put a note in the update dialog and in Preferences that performing an update requires administrator privileges - at least until that's no longer true.

I updated to 6.9.5 and Help>About shows 6.9.5, but if I do a check for updates it shows me 6.9.5 is available for download and asks if I want to update.

That's because there was a bug with one of the fixes I did for 6.9.5 so I fixed it again and released it under the same version number. If you perform the second update you are in fact getting 6.9.5.1 and you won't be asked to update again.

iamstarbuck wrote:

that performing an update requires administrator privileges

TDLUpdate definitely needs admin privileges and so it requests them using UAC.

TDL, on the other hand, ought not to need admin privileges just to download a text file to the user's Temp folder. I will see if I can code a backup plan for the rare occasion that the security settings have been messed up.

It's not TDLUpdate that downloads the script, but TDL itself. This is so that if there are no updates to be found then the TDL does not need to be closed.

However, not being able to write to your temp folder even by a non-elevated process is unexpected. Seems to be a recognised security issue[^] for some people. The 'best' solution is probably to make your temp folder accessible rather than to run TDL elevated.

I have never got this working. Always get that message. To date, I have ascribed this to security settings at work, although it doesn't work at home either (same laptop). I run WinXP SP3.
So I still download the zip, and copy over the current .ini etc...

I wonder...
1. Could this be made "better" by having the updater return status codes for different error conditions, and report them individually.
2. Could this problem be due to some over-eager antivirus filters sucking up anything named ".exe" (while possibly still reporting success)?

My money would be on a combination.

For the ones experiencing the problem, could you please state if you have an anti-virus software intercepting your HTTP streams or filesystem, and if so what.

Another request.
when I do a print preview while in "List View", Visible columns only,
I get the "Parent Task ID" which is not visible (in my case)
and with List View, the Path is missing even if displayed.

If I choose "Custom", "Path" is not in the list

Patrice

“Everything should be made as simple as possible, but no simpler.” Albert Einstein

My clients frequently ask for a notice when we reach specific milestones:
- The "half-way point" in terms of a due date, or actual vs estimate time.
- Or when specific tasks are in a specific status like In Progress, Need Info, or Complete.

I'm thinking the Reminder mechanism which is currently only based on Dates, could use an enhancement to open a reminder when other conditions are met. These would then need to be dismissed to not recur until some other condition is met. Note that this also implies multiple reminders per task: Let me know that some action is required when the Status=Complete, Or when the ActualTime>=(EstimateTime*.5).

Perhaps this can be linked with the existing Filter mechanism, so that when a specific filter yields a non-empty result set, then a reminder is displayed. I think that would be very elegant and easier to implement than to hack up the Reminder mechanisms which work well for their purposes.

Does anyone else have similar requests which might prompt requests for TDL enhancements?

As I think about this, I could do all of this with an external routine and a UDT using the new library. Hmmm. If this isn't a good fit for the TDL core I'll probably take this on as a task for an add-on.

Dan, this also makes me think it would be nice to have the ability to execute one or more UDTs from the command line. This way a user could automatically run this check, get their reminders, and process each one before getting into the normal grind of the day. This is exactly how Outlook works...

Sometimes I forget to click the time tracking and enter the time in manually. However, I'd still like to get the Analyse Logged Time for these manual entries. Also, I noticed that I'll get dual entries for the same item as well. Is there a safe way to modify the log file to aggregate tracked time and get rid of duplicates?

Having said that, let me back track a little for what I'm trying to do:
My goal is to track productivity with hours worked per day on certain tasks--for me personally. What I don't want to see is lapses in time where productivity just wasn't happening... Right now I just don't see an easy way to do this unless it's creating a subtask that has the current day's date and then filtering on the title to get all the subtasks with that date to sum those day's hours.

I don't quite understand the entirety of your post here but I'll respond to what I do understand...

I look at the log as being the detail for everything that I want to log, and then I use Excel or other mechnanisms to filter the data later. Compare this to trying to get specific kinds of logging into that CSV file. So there is stuff in there that I don't want to see for some applications but I personally want as much data in there as I can get so that I can do better post-processing later. Perhaps that approach might help you to use the data better or differently.

As to making adjustments: I log time for my clients. When I start working on a task I click the clock and when I move to anything else I turn the clock off or I click something else. It's taken a long time to establish that discipline but it's well worth it. But we all make mistakes and sometimes I don't clock in or out. This is where we can now post Adjustments to the time log. If you look at the CSV (ctrl-L from TDL) there is a column that shows Tracked time. You can also log an Adjusted entry from menu>Edit>Other Task Attributes>Add Time to Task Log File (my hot-key is ctrl-alt-shift-A). I use that a lot to add time that I missed, or to add a negative amount to time that I've logged. Note that I don't want to modify the log, to correct an over-run, I always post adjustments to add or remove time. This nets-out in the Analyse Logged Time report. Note also that this conforms to general accounting rules - you don't delete transactions, you post adjustments to preserve the audit trail.

About unproductive time: You can create a single task that you clock into when you're Not doing anything else. The report will then total up this time for you. ( Just this last week a friend proposed (as a joke) a mobile app that tracks Anti-time, so you can track time you've wasted playing games, watching TV, day dreaming, and doing other things that are completely unproductive. )

So again, I was a little lost from your post here, but does any of that help?

Certainly helps thank you. "Add Time to Task Log File" seems to be the ticket to get me started. I was, in fact, missing time entries, would update the task manually and not see the output in the log file. Before that, though, I was a bit confused about my entries. When I forgot to record my time, I would actually hit the timer to create stub entries in the log file just to get something recorded in the log--however, now I can't really delete those entries--sounds like. Then, came "Add Time to Task Log File", but now I'm stuck with those bogus entries in the log I made previously--which I can filter out--unless there's an easier way to safely get rid of them.

To avoid using the log, I was considering creating subtasks like the following:

02/04/2015
02/05/2015
02/06/2015

and logging my time to those subtasks under the real task I'm trying to accomplish. Then, I could say, type 02/05/2015, in the Title and filter all my Tasks by that particular day and get my summed time at the bottom right--still pondering on this one.

Since ctrl-L opens the log CSV to Excel by default (or whatever spreadsheet utility you use), it becomes easy to open the log to use the external tool for filtering, sorting, and other operations. If using Excel, the file opens as Read-only so it's safe to manipulate it. If you need to save, SaveAs another file (XLSX) and then do the manipulation there. Think of that CSV file is purely the log from TDL, it's not "ours" for manipulation.

If you don't use Excel, there are free apps as well as Google Docs. These are all fine tools for filtering and doing calculations.

As to extra time entries, when the Analyse reports came out I stopped trying to report detailed time to my clients and started reporting summaries by day by task with the analysis. Clients don't want to know what time I clocked in/out, especially when I clock out for coffee, washroom, etc. For my purposes I can refer to the detail as above. So don't worry about having extra detail in there.

But let's say you logged time on the wrong task, or you turned on a task and then turned it off a minute later. Now you might have this odd minute on the Analysis for that day. This is where you can do an adjustment. Setup a hot key, again I use ctrl-shift-alt-A to avoid conflict and accidents. It becomes very easy to apply a credit of -1m (1 minute deduction). With that posted the Analysis will no longer show the odd minute since the +1 + -1 nets to zero. Yes, You see that +1 and -1 on your TDL CSV log, but it's good that You know what happened. Once in a while I'll look at the CSV and notice that I forgot to issue a credit, or that I clocked time against the wrong task. So I just issue a negative time to the original task and a positive time to the correct one, setting the date and time in this case. The Analysis then reports the correct data in the correct order.

You really don't want to mess with the CSV file. In current/prior versions that file is in Unicode and has a special marker. If you save the file with some tools the marker is lost and TDL will have a problem logging the time properly. Dan is changing that format, and this May avoid that problem. Also note that whenever you update your log with time, TDL now saves a backup of the CSV, just in case corruption occurs.

I don't like the idea of creating a new task per-day. It inelegantly duplicates built-in functionality. Let's try to get you logging time with the tools that exist. Then you won't get frustrated later with "look at all the crap I need to go through to log my time with this stupid thing".

If you have a good application for a process that seems outside of the scope of TDL, Dan is very good at acknowledging and considering enhancements to the software. But in a lot of cases here we see that people just need to learn to use the tools that are available. It's not a matter of changing how you work for the tools, just finding how to use the tools in a way that fits with how you work.

I'm currently re-working the Task-Tree and List-View so that columns can be re-sized and re-ordered, and so that the task column can be scrolled horizontally independently of the attribute columns, which will also support horizontal scrolling.

Whilst on the surface I hope that the changes will not be dramatic, it is nevertheless a big architectural and code change with the possibility of all sorts of subtle interaction issues that we will need to discover and fix.

As a result, I am proposing that version 7.0 deal only with this specific piece of work so that we can iron out all the issues before that gets more complicated by the presence of new functionality, which will follow in 7.1. This also means that 7.0 will be available sooner and we can then look further into the future.

Sounds good to me. Personally I prefer evolutionary changes to revolutionary. Too much change at once isn't good for anyone. In particular here, many of us rely on this application for billing. This is literally our bread and butter that we're tracking. I prefer smaller changes introduced and tested in shorter cycles than huge changes in different areas that have a high risk of major interruptions. I enjoy being able to participate in the shake-down process to help debug and improve the software, but I can't do too much of that while in the middle of trying to get real work done. So again, less dramatic changes are better for everyone.

I'd also like to see your initiatives for better reporting deferred until we can shake down the new library and see what we can get from there. That might preclude a lot of your efforts with writing functionality like this into the core. So I'm happy to see that getting deferred to 7.1+. The less time you need to spend on reporting the more time you can spend on other aspects of task management.