When I first released ToDoList more than 11 years ago it was as a consequence of exploring some UI ideas, the principal of which was using the non-client region of a tree-view control to draw attribute columns.

But while this satisfied my research goal it had a major drawback: The attribute columns could not move independently of the task titles meaning that if you displayed too many columns the task title got squeezed and some of the attribute columns might not be visible.

In addition there was no column reordering or resizing because I would have had to write this from scratch and that seemed too great an effort when the built-in Windows list-view gave you that for free. So I pushed the problem into the background and palmed-away questions as they came up.

Then sometime in 2012 I started to think about creating a Gantt plugin and I realised that the 'tree-part' and the 'bar-part' were going to have to be physically separate because the 'bar-part' was definitely going to need to scroll horizontally but that scrolling could not cause the 'tree-part' to be hidden. And I further realised that solving this might also provide the solution to Task-Tree attribute columns issue.

So I started work on a 'Tree-List-Syncer' whose primary goal was to synchronise the vertical scrolling of either a tree and a list or two lists, positioned side-by-side. Additionally the LHS widget had to hide its vertical scrollbar and instead respond to scroll events from the RHS widget.

The Gantt plugin was released with 6.7 in 2013 and proved successful as a solution yet it still took a couple more versions for me to summon up the courage to pull open the guts of the app to replace the Task-Tree and List-View. I think I was still hoping that the Gantt plugin would reveal a huge flaw in my approach so that I didn't have to do the work!

But here it is. Both the Task-Tree and List-View now have task attributes that can be scrolled horizontally without impacting the task titles. They are divided by a splitter bar (which can be effectively hidden in the preferences) giving total control over 'pane' widths. Attributes columns can be reordered and resized by dragging the column header dividers ala Explorer.

I do understand that some of you will find these changes upsetting but they had to made in order that other more important usability features could be included to keep ToDoList relevant.

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.

History

7.0.13 (04 Feb 2016) - Mostly likely the last update of 7.0

Fixed uneven task row heights on Windows XP 64-bit

Fixed incorrect strike-through in Find Tasks dialog for incomplete parent tasks having all their subtasks completed

Fixed doubled-up Help Menu separator on XP

Fixed translation 'Cleanup' button not saving changes

Fixed XML encoding for Unicode tasklists

Fixed tasklist tab-bar resize bug after double-clicking on titlebar

7.0.12.1 (20 Jan 2016)

Fixed loading of Ansi tasklists

7.0.12 (14 Jan 2016)

Fixed bug where pasting a text fragment from Firefox would display the wrong source URL

Fixed List View selection render artifacts in full screen when resizing the title pane

Fixed inability to tab to Status field after making the field 'read-only'

Comments and Discussions

For what it is worth, I have always found it a little logically strained to combine the date range filters with other attributes or statuses, such as all, complete, incomplete, selected, flagged.It has never really caused me any issues though in the way I use TDL.zajchapp

Sure.What I mean is that the date range filters are useful for finding tasks within a date range. Attribute filters are useful for finding tasks with a particular attribute (e.g. flagged or completed status). By combining these in the one filter, means flexibility is lost. I understand the 'Show' filter is a useful compromise, as it is a useful way of bringing up common views. IMHO it isn't logically 'pure' though, and means certain views aren't possible.

For example:I want all flagged tasks due by the end of the month. By using the existing show filters I can only get all tasks due by the end of the month. I can't specify to see only the flagged ones in that date range. Similarly if you wanted to see all completed tasks in the date range (for reporting purposed for instance). You can use sorting to help though.

I am not sure this needs 'fixing' though, as we have the 'Find Tasks' functionality. This not only allows for more control over date ranges, but a wide variety of additional attributes can be included in the query you build. And when we can save a set of custom views/queries, all will be well. At that point, I will probably mainly use self created filters. And that is also why I would be keen to be able to remove the current built in ones.

PS: The functionality that the filter bar remains active when a custom filter is applied would be great. It could mean that you don't need to create a unique filter for, say, every member in the team...zajchap

I fully agree with this detailed explanation! It is exactly what i think. But your english is better than mine

However, I don't agree with the conclusion when you say That find task filter is the solution. Find task filter allows more control, Yes, but the 'selected tasks' filter is not possible via the find task functionality... And sometimes uses the find task filters is not so user friendly than the standard filters ( i need to modify my search Filter in ordre to have exactly what i want)

So IMHO, a little Fix / improvement in order to separate date filters from the others (uncompleted, selected, flagged, etc...), would be à good thing. And this "new" filter should remain enabled even in case of custom find task filter.

The selected task filter can be useful if you have a tasklist with several "topics" with several related tasks.For example one parent "TECHNICAL", one other "BUSINESS". Sometimes, I want to focus on the TECHNICAL part of the tree, and export related tasks (in html), for sending result to the technical user who don't care about business tasks.

So, regarding my request in this post, I need indeed to first filter, in order to see for example the current tasks of the week, then I want to focus on a specific part of the tree.

Thanks for the explanation. I can now see the usefulness if you can then see the children of the selected task. For exporting, I have just used the selected task option in the dialog - after selecting the appropriate tasks manually in the tasklist.

One little bug crept in:The steps:1. Enable 'view>show filter bar'.2. Create a new custom field / column (Data type: Date); Attribute label (not column title) = 'Work On'3. Create a new tasklist with four tasks4. Make sure that one task has a due date (2012-Nov-23) and a 'work on date' (2012-Nov-20).5. Create a new filter (Due Date relative - occurs on or before - t+7 and 'Work On Relative - occurs on or before - t+7) Save the filter (name: Testfilter)6. Apply the filter (the find tasks window disappears).

Only one task should be visible in task tree view now (the task with the dates).

While using/testing the 6.6 Dev Release, I had something strange happen: all of the due dates, start dates, statuses, categories, etc. blanked (disappeared) (for no reason) for all the sibling sub-tasks to the one that was hilighted. This was a bunch of tasks (over 300) in a parent task called "Main Tasks". After saving the TDL file and looking at it in wordpad, all of that stuff WAS really gone from the tasks. The actual choices for category, status, etc. WERE still in the TDL file (at the bottom) I'm not sure what I was doing at the time, but I restored a backup and it happened again (not sure what I did to cause it again - seemed to actually happen by itself)! I had to go back to the latest official version (6.5.8), because this was my actual tasklist that I use at work. I just wanted to let you know that this happened - might be another bug that crept into THIS version, because it never happened before (on other versions)-Steve-

these were missing from the TDL file STATUS NUMCATEGORY CATEGORY DUEDATE DUEDATESTRINGI have inheritance turned on for: Status Category Due Date Flag TagsAnd the checkbox for "Continue to update subtasks as parent changes" is CHECKED. However, the Due Date, Status & Category for the tasks disappeared all at the same time AND the cursor was not on the the parent task when it happened so I don't believe it is something I did by accident (twice) - but I can't be 100% sure. Let me know if you find anything. Thanks! -Steve-

I like this program very much, but very often, when I mark a subtask ask being complete, all the tasks above it disappear from the screen! Then I have to do a collapse-all and expand-all to get everything back on the screen. Another way to get everything back on the screen is to use the up arrow. Is there any way to not have that stuff disappear? Thanks!

An active filter might explain that the "tasks above it disappear from the screen" and that they reappear when Member 9172785 uses the arrow up key.

There where several posts in the last months that dealt with little problems with the view and the necessity of the use of the arrow key to solve that. I can't recall them all but I think this little problem started with the filter option w) and showed up in different situations.

It probably does not happen when there is no filter, but I usually use at least one filter due to having a large number of tasks. It is happening right now when I show "Tasks Due by Today" and have 5 things checked under the Status filter, but that is not the only filter combination where this happens. While testing, I just noticed that UNDO (Ctrl+Z) can also make this same thing happen, and upon further examination, it's not only the tasks above the one I'm checking off that disappear, but some below too! I will try to examine what is happening more carefully as I use ToDoList to see if I can identify any more clues or patterns when this happens. One more thing (if it matters) is that I have some top-level tasks like "Daily Tasks", "Weekly Tasks", etc. that contain my actual tasks, so all of the tasks that I check off are actually sub-tasks of these-Steve-

It IS fixed (in the 6.6DR version)! Tasks are no longer disappearing when I mark a task as complete. They are also NO LONGER disapearing when I do undo or change filter settings. This is MUCH better. Thanks for the quick fix for this issue! -Steve-

Could we have a little more control over the modified date field? I often find that owing to my poor typing skills I have to edit tasks in order to correct typing errors. This is recorded in the modified date field, but for me such actions are not significant modifications meriting recording in this way.

So, would it be possible to allow the user some leeway in changing the modified date field for any edits?

First: Thanks for the great Author Dan. i just downloaded yesterday this wonderful program, and It's amazing how outstanding and superior this program is, much much more than many other "costly" programs that i tried in the last few months. simple and neat, flexible, beautiful and perfect design, great features to the need, excellent functions, and it seems to go forward with much more.

one of the suggestions that i have for the next update of this program, that in the preferences at the settings for colors based on 'due date' 'category' 'completed task' and others, should also have all other formatting options to chose for each criteria, as font, font size, bold, underline ETC. this will b great when someone wants to define different formatting for a few conditions of tasks in the task list at once.Thanks Again