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'

You're right, but I don't want to uncheck this option. Frankly speaking TDL is the only application without "Exit" command in the file menu I've ever seen. Don't bother, I'm just grumbling I was surprised not finding the Exit command and I let you know. That's it. The only moment when I needed was the occasional bug in windows. So I suggest EOT, the case is not worth so big thread

After reading the post from Klaus about importing emails from Outlook as file-links, I gave it a go using Outlook Express. I noticed that if you drag an email into the Comments field, the gray text called "Type some comments" remains, until the view is repainted in some way.

Note 2: To reproduce, ensure the email is small/does not contain hyperlinks - otherwise the comments field will be repainted to scroll/make the hyperlink turn blue

Note 3: I noticed that when you drag a text file (e.g c:\bob.txt) into the Comments field, as soon as the mouse enters the Comments field the "Type some comments" text disappears. It does not disappear at this point for emails.

Dragging email (or different emails)from outlook into comments field it's exactly my "dream": I think it could be very useful for all the people that use todolist to follow and to coordinate many project. For each task I receive lot of update with email. If Dan realise this feature TDL can be also an excellent archive for the important emails related to the different project.

May be it's easier (1) to change task colour automatically if task or any of its subtasks are 'Due Today', then if (2) user have to manually every morning flag 'Today tasks' (as I do now). Or (if it is easier to implement) to form virtual 'Today To-do list'.In any case - it'll be very-very useful to be able to see all 'Today' tasks.

I was looking for a stylesheet to print out a very simple task list. I found some samples on the web, but they didn't really meet my needs. I'm not a real programmer, but I did watch a terrible movie called "Hackers" once. So, I gave it a try and came out with something that looks like:

does anyone know how to create a direct link to an e-mail stored in the MS Outlook .ost file?

Here is what I do:

- I installed Google Desktop- with Google Desktop Search, I search for the Outlook mail that I want to link- with mouse right-click on that search result, I get the context menu and I click on 'Copy link'- now switching to TDL: in the File Link Editing Box at bottom, I paste that link- now, clicking on the 'Show' button right of the File Link 'Browse' button, Google Desktop starts, showing this mail

This is for sure a pedestrian method ... is there any better way how to create a link which leads me directly to a MS Outlook mail ?

I tried both, Outlook Express that comes with XP and Outlook 2003.Dragging a mail element directly to the desktop creates a .msg file.Dragging it directly to the TDL File-Link editbox is not possible ... you are right, it should ...

thanks for this link, this tool works perfectly for me.I am using Windows XP, Outlook 2003 (the website says Outlook 2007 won't work)

Here is in detail what to do:

- Download 'Linker for Windows' (it is free)

- After installation of 'Linker for Windows':

- Start the program (if it is running, the icon is found on the Windows system tray)

- Right-click on the system tray icon: select 'Office Format'

- Open Outlook, go to (highlight) the item you want to link

- (Double-) Click on the system tray icon

- Go to TDL, paste (Ctrl+v) into the TDL File Link editing box

- Click on the 'Search' (right to the 'Browse') buttom of the File Link editing box: the e-mail should open directly

Note: if you move the linked e-mail into another Outlook folder, it cannot be found anymore. However, as the 'Regarding' text is stored in the link, it should not be too difficult to find it even when moved.

I want to call web service return in C#.net inside VB code, for the webservice i have created webPorxy and after compiling i got the dll, then for the purpose to use in VB. i compiled it with regasm "ProxyDll_PATH" /tlb:"Where to create the dll"now i have open visual basic project and get the ref of this but, i dont know how to create the object of this dll in Vb and nither i am getting this in to my form nor i m able to get the method of the proxey to call....while i am able to find it into my object browse window but without method....can sombody help its urgent?

Of course, there is the measure to change those though, it may be diffcult or takes much time for users who're not good at programming like me.It's really useful program. and i hope those functions can be added.^^

By now this work has become so classic, it's almost a standard inclusion in every developer's tool kit.

However, when I clicked on Help->ToDoList Help to find certain information, it came back telling me it couldn't find the necessary files. This is where I believe an entry in the Help menu, offering an FAQ section, would have been most helpful.

I notice that the version history (Version 1.0 - 4.8.x) already being removed.It is nothing wrong. But if you don mind, could you please add the version history 1.0 to 5.0 into Help Documentation? It is something very excited to get a view on how ToDoList grow from small and simple last time until powerful and user friendly application today.

i hope i'm not repeating an oft-posed question (i searched the forum and found no mention of sqlite), but have you considered replacing the clunky xml format with sqlite? there are numerous wrappers for vc++, such as http://www.codeproject.com/database/CppSQLite.asp.

if you arent familiar with sqlite, it's amazing: it supports virtually all of ansi 92, and the dll is under 200K. i saw a thread back from may discussing ODBC options, this seems like overkill to me. sqlite would cover every multiuser case except teams without shared file access over vpn/lan, while not changing the installation difficulty/install requirements/size footprint!

just wondered if you'd considered it. it would allow things like multiple comments for a task (with notification if other users comment on your tasks), one file for an entire team, that they could all access concurrently with no checkin/checkout issues, all manner of arbitary reports with all of the power that sql has.

while i'm not an vc++ developer (though i wrote some c/c++ apps back in the day, and have access to visual studio), i have extensive experience in sql (that's most of my day job, sql programming), and would be eager to assist in any way i could on the sql side of things, if you wanted help!

this seems to be the only glaring structural weakness in your awesome todolist, and it seems very fixable to me.thoughts welcome from Dan and others!

and would be eager to assist in any way i could on the sql side of things, if you wanted help!

Well, if you're prepared to do some of the creative thinking then that be a great start.

The biggest obstacle to having a db backend is simply that ToDoList's design is file-based through-and-through and that is unlikely to change.

Therefore I think it's important to accept that it is unlikely to be a fully integrated and seamless solution, rather it will use the importer/exporter plugin interface to achieve it's goals.

My current plan is to have the db load routines present a query interface to the user which would then construct a temporary standard XML tasklist (based on the query results) which TDL would load and edit as normal. Then when it came time to save the mods, the save routine would convert the XML changes back into database updates.

I anticipate that some additional XML tags may be necessary such as whether a task is editable and the database key for the task so that mods can be synched up.

My current plan is to have the db load routines present a query interface to the user which would then construct a temporary standard XML tasklist (based on the query results) which TDL would load and edit as normal. Then when it came time to save the mods, the save routine would convert the XML changes back into database updates.

it seems to me that an additional file format should be supported then, containing the query for the current tasklist (a virtual tasklist file). this way these saved queries could be as simple as tasks assigned to a given user (allowing multi-user with the same db), or something like what i saw posted today, a request for a "today" virtual tasklist (the query just using today's date). this additional query file would then load in the xml tasklist and edit as normal (as an aside: i'm not familiar with your internal structure, but why arent these changes just stored in memory? seems like overkill to write to an xml then commit to a db. i assumed that the xml file was loaded into memory and then manipulated there until a save was performed: this isnt correct?)

the approach you describe has shortcomings with respect to concurrency. it seems to me that an update query would have to be performed on any task update, and the xml file would have to be refreshed every x (30?) seconds. if you waited until the list was saved, given the nature of overlapping virtual tasklist files, you'd doubtless run into overwritten tasks. the entire tasklist can no longer be checked out atomically, in order to reduce the likelihood if editing collisions, commits (updates) should be made as soon as a given task is edited.

2 ways to go with this. if a task loses focus, all fields could be checked, and if any changed, run the update query (which also increases the revision number described below). you could also use a "save" button for each task to be a "dumb" save and revision incrementer, but this is a pain for the user just to save the computing time of a diff on each field.

i think you can still get away with refreshing the whole list every x seconds to retrieve changes by other users, but it's definitely not ideal. ideally, the xml format would be eliminated entirely, removing the need for polling the whole virtual tasklist contents at once. but, you say this isnt likely, so ok, we'll work with what we have!

i'm thinking also that a column for revision number per task would prove efficient for determining if a task has changed or not, as an alternative to the brute force intermittent polling approach. whenever a task is selected, the db is polled, comparing the revision column of the local task vs that on the server. if they're the same, then no other fields need to be pulled or checked, and you can display the task as is. this same process should be performed as a task is being committed (saved, deselected, when it has changed as described above) to prevent conflicts, with a screen showing the differences. if no difference in the current revision number (local vs db) (or an override on the changes/merge/whatever the user does), the revision number is incremented and the changes are saved.

this avoids the massive polling and ensures that every task is up to date with a minimum of querying...

also, since most people dont display every field, you could restrict the diff procedure (to determine if the task is up to date) to only the fields shown, this should optimize it a bit.

sorry if this is a bit jumbled, i'm very pressed for time right now, and just whipped it together. let me know your thoughts

Unfortunately, the RTF specification does not appear to support a horizontal rule. All the research I have done suggests that it is always achieved using a stretchable image file which I'd like to avoid because of the impact it can have on file size.

I have seen this feature in "My Notes Keeper" and it seems to work without an image, probably they are using an empty table or paragraph with border. When I export a note with a horizontal bar as RTF, I get the following:

With such a bar you could easily separate a customer request (e.g. pasted from an email) and your own notes about what to do or what has already been done to it. So it would be very helpful in ToDoList.

I was trying to figure out the significance of Dependency. Does it expect an ID of the task? If yes, where can we get the ID of the task? Nowhere, TDL gives the ID. But if we give a random ID (like 0 or 1 for root or first element) and click that lens, it says an error.

it seems that the 'Encrypt tasklist' function is limited by the number of tasks, regardless of their title or comment length.To check this, I created a tasklist called 'test.tdl' with:

- a parent task with 99 subtasks, all with a title length of only 1 character- I copied the parent 11 times (now 1200 total tasks)

Trying to save this file (with CTRL+S), with the encryption activated, I received the following error message:

'The tasklist 'test.tdl' contained specific characters that could not be saved. Typically these will be found in a task's comment's .... '

However, this test.tdl file had no comments at all. Deleting one task at a time, always testing the 'Save'-function, I found out that the encryption works fine with 1109 tasks. With 1110 (sometimes with 1111) tasks, TDL aborts, creating the files:

test.tdl (size 0)test.bak (size 520428)

Any idea how to use the encryption function with more tasks?

Thanks, Klaus

PS: the limit of 1109 tasks may vary, depending on the 'Preference'-options selected.

PPS: If a parent task with subtasks is deleted, the task-counting (found in the status bar at the bottom) does not seem to be accurate any more.

I admit: I consolidated different task files into one, and this one contains now more than 2000 tasks ... And it works fine! Very stable, and speed improved a lot with 5.3.3.I am using TDL for business, it does exactly what I need (and I tried a lot of task managing / project software ...).