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'

ToDoList uses a simple locking mechanism (check out) to allow one person edit-access to the tasklist. When that person has finished editing they release the lock (check in) to allow others to edit the file.

I've been testing and experimenting with the "recurrent task" thing. I just don't understand how you use this feature.

Say I've set some task up as a daily task: "Daily", "Every 1 day"...

Calculate next occurrence: "from due date"...

When I complete this task: either "Create new..." or "Reuse"...

As I understand it, nothing at all will happen unless you initially set the "Due date". So I set it to tomorrow on day D.

Next day (D+1) the task is shown with a red font.

My question is: what am I then meant to do so that it goes back to "black font" on D+1 ... but will then show red again on D+2? (A: with "Create new..." and B: with "Reuse"...).

What is the function of the tick box to the left? Checking this seems to draw a strikethrough and "grey-out" the font: ticking means "task completed", right? So if your setting is "Reuse" what are you meant to do? Tick or not tick?

"Show red.." depends on the settings "Pref - User Interface - Fonts and Colours - Due task colour / due today colour". Take a look there and you will understand the behaviour (and the ways to customize it).

"Tick it" usually says "task complete / strike strough / grey / .."But a recurrent task behaves depending on "Create new..." or "Reuse"...- "Create new" lets the original task as "completed", but creates a clone of it with new ID and new calculated due-day.- "Reuse" sets the just completed task to "uncompleted, but new the next recurrence"

It depends on the importance and the required retrace-ability of the task which option is better for you.

So if your setting is "Reuse" what are you meant to do? Tick or not tick?

You always tick to say 'I have finished this task' and then the software will move the due date to the next day and untick the completion box. ie. As you complete the recurring task it automatically jumps to the next recurrence.

Again, I probably have to remind you all that I'm not an IT professional. Apologies if I'm asking things which TDLers find obvious. Maybe my questions will be useful for future non-IT-professionals.

I keep the TDL7 files under D:\apps\ on my system... it seems to be about 8 MB in size currently. This D:\apps\ location isn't a location I back up every day.

But I want in particular to back up my main list at least daily... so I found a way of doing an "auto-export" every minute: Tools > Prefs > Categories > File Actions (more) > Saving > Automatically export after saving.

This exports as an HTML file (to a location where I do a daily backup).

But when I then wanted to test reimporting this HTML file I couldn't find HTML as one of the Import Tasks > Format choices. Can someone possibly explain how this works?

You must not mix up "Export" and "backup". Export is a conversion of format (and maybe data), and depending on your settings (What are you exporting to which format?) there is a reduction / a loss of logic and data. For 99% "Export" is for usage in other context (presentation, ..) or in other formats, but not for "reusage".

To "really, unchanged backup" you need only to take a look at "Preferences -> File Actions (more) -> Backup", and you will find 4 "Auto-save" options.

(BTW: You could also select "Export tp TDL", but depending on your settings the data also can be changed.)

I have now tweaked the backup thing so that it saves to a more suitable place. This is better (for me) than having the "backup" folder in the app directory tree, but it is a bit blunt - ideally I'd like to backup just one particular project...

... and in my amateur application I have a hotkey which 1) takes focus to the Comment box; 2) puts the caret at the bottom of the box; 3) does a new line; 4) adds the current date in YYYY-MM-DD format.

A hotkey along those lines in Todolist 7 would already be nice.

But it occurred to me some time ago that a next step might actually to make each date-stamped entry a record in its own right in a table... This would make things a bit more complicated to print things out, perhaps, but it could also have a lot of analytical advantages.

I haven't got a clue at the moment how your database (if such it be) underpins the structure of the lists. In my implementation each task/tree node is a record in a table, with an ID field, and a "parent ID" field. Obviously the "history elements" would have a "task ID" and there would be a one-to-many relationship.

PS Sorry if this idea is old and has already been thought about and discarded...

... and in my amateur application I have a hotkey which 1) takes focus to the Comment box; 2) puts the caret at the bottom of the box; 3) does a new line; 4) adds the current date in YYYY-MM-DD format.

IMHO functions like this should stay userdefined, with tools like AutoHotkey and other. I'm sure that the next user whishes a hotkey for 1) save the file, takes focus to the Comment box; set font to arial2) puts the caret at the bottom of the box; 3) does a new line plus horizontal line plus new line4) adds the current date in DD.MM.YYYY format ...

So this cannot be solved ...

Member 12436111 wrote:

This would make things a bit more complicated to print things out, perhaps, but it could also have a lot of analytical advantages.

If you have a fine stylesheet or you know how to create them, you can print what you want ...

Member 12436111 wrote:

I haven't got a clue at the moment how your database (if such it be) underpins the structure of the lists

There are good comments on the table here. I tend to agree with Pierre on a couple points. ToDoList is great at what it does. Some of us, including myself, want it to do more to help us to manage our workflow. But there are Many cases where it would be better to integrate other first-class solutions with ToDoList, rather than trying to make this into a Swiss Army Knife, one-app-does-all kind of solution. There's no shame to integration, and a lot of advantages. There's no shame in ToDoList being "just" the best task management solution available, and using other tools to do what they do best.

In your workflow, I'm thinking you want a database, and ToDoList can refer to that with links, so that you can access details of How you accomplished a task, while TDL records the status of the task itself. So TDL isn't the tool for itemizing payments or membership renewals, but it is the tool for recording when these things need to be done, reminding you that they should have been done, and for crossing off the fact that you've accomplished what you intended to do.

For such integration, I again agree with Pierre that AutoHotKey is great. I also use PhraseExpress ... check out their website docs, watch a couple videos, try the software - once you get familiar with it you might be hooked for life, as I was.

As to specific fields that can be used to integrate with an external database, TDL has custom fields and file links. And you'll notice that ToDoList allows you to use tdl:// links on your system to jump to tasks. Well, if you can create this kind of reference in other apps (whether through your code or something built-in elsewhere, then you can enter a comment in TDL which points to a specific transaction in another app.

One example of that might be bugzilla, or other "issue trackers" where in your case you're not tracking "issues" or "bugs", but you do seem to be looking to create a "case" or "ticket" to record an event. So you might create a "case" that needs to be handled, like going to the library, and each comment you put in there does indeed get a timestamp. With most of these apps you can also add custom fields like FinePaid (decimal value), MembershipPaid (Boolean/check), etc. So in ToDoList you might have case://345 which then links to your documentation of such events. This is the way we track software bugs - we link to other structured information rather than trying to fit these fields into ToDoList, which is Not intended to be a general purpose database.

Having said all of that, without automation, you Could get your workflow into ToDoList... Create a general purpose recurring parent task for Handle Library. So this will come up once per week or whenever you schedule. Under this you'll have tasks for Return Books, Pay Fine, Update Membership, and other such details. If you have no fines, just mark the status as Not Needed or Complete. If you pay a fine, there's a built-in Cost field. When a single event has been documented, flag it as Complete. For follow-up reporting, you can sort all tasks by name, or issue them tags or categories. This WILL give you a database of sorts that can be used to quite nice reporting using the Transform function.

As you see, the tool is powerful, and Can be used in various ways. The ongoing question all of us ask from time to time is "Should we ask Dan to build in some functionality, is it already there, or might it be better to do this outside the box?" We might get answers that change our vision of how we Like to do things, or how we think things Should be done. We need to accept on a daily basis that we need to make occasional concessions in order to get an overall great solution. And then there are those times when Dan says "good idea, I'll add it in the next release". Bonus! One of the reasons why this software is so cool is that we have those options, where it's not so easy elsewhere.

And you have a community of people here who like to brainstorm like this.

Yes, with my amateur attempt at a Todolist, which (in intention at least) has a lot of things in common with Dan's brilliant app, I came up against the question of just what I wanted the thing to do: should it just be a simple todo list, the primary function of which would be to flag up tasks that needed doing, or continuing, 2 or 3 weeks from now, or every year, etc?

But I inevitably started wondering, yes, but what about "archiving" tasks that have been done, and finished with...? Particularly with important things in life, like running a business or paying taxes, you might need to refer back to things that had happened years ago... Given that my solution was database-based, it was easy to just exclude tasks (or subtrees) from the "active" tree.

It's amazing how many issues this then generated: the question of "maintenance" of the archived tree, in short.

Anyway, I've had a couple of reads of your response and there are some things I understand and some I don't. I really wish there were one of those "door-stop" 1000-page books on Todolist7, or even just a Todolist7 for Dummies. I know there's the Wiki... but I wonder whether it actually documents the sorts of techniques you have mentioned... I shall endeavour to look.

PS I already use Autohotkey... I wonder whether a given AHK hotkey combo can be made to apply only in the context of a particular app (i.e. rather than regardless of which window has focus). In my amateur app, which was written in Java, I could really tailor the use of hotkeys very precisely.

You may notice from the wiki pages (which need updates...) that I've tried to document core functionality while also creating pages that describe how ToDoList can be used in various contexts. So it's not just about which buttons to press, but about why you might want to use the various features. I believe this is your intent with the ToDoList for Dummies concept. The Wiki is that documentation.

Please note the link in my signature here for the Wiki Suggestion Box[^]. You are welcome to write up minimal notes there which I will incorporate into the wiki. Or we can exchange notes via email. (PM me off list for contact info if you don't have it, or send your address to the Suggestion Box, I don't publish email addresses in public.) Or you can use GitHub, create an Issue, and start posting content there for review and possible inclusion (although that's not ideal). I'd like to invite you to open a single thread in the Google Group too where you can solicit feedback on your contributions and sort of build your documentation as you go in collaboration with others, but Dan may not agree to such usage of that medium. ( ? )

So, no need to wait to write a book ( I write a book in every forum post ). You can start now, and actually your soul searching now will be quite valuable to others who are in the same position. After we get to know something it's often tough to remember what it's like not to know it, and perhaps the frustration of trying to get info on specific topics. Post questions if you don't see something in the wiki. HowTo questions allow others to respond with how They do something, which can help everyone. And this entire process can help Dan to see where there may be some weaknesses for an occasional helpful tweak ... that happens a Lot.

A couple of your requests may already be implemented in a way:
First, ctrl-D to insert the date/time.
Second, note a couple options under Prefereces>User Interface>Tasklist Attributes Date/Time formatting: Append the users 'Created By' name when pasting the Date/Time, and Append the following text when pasting the Date/Time. I put a space in that field. Someone else might want a comma or colon or hyphen...

From that same preference page, under Other, see : Display comments after task title, and Display only the first line of comments. So you can have a short task title and the first line will automatically display in the grid.

I tend to go more for clicking around on a menu than using key commands . I guess I was wishing for the context menu in the comment field to look more like the Edit menu--I really like the way the commands are organized on the Edit menu, with all insert, copy, and paste commands listed together in groups, and mostly in flat lists not involving submenus.

iamstarbuck wrote:

Display comments after task title, and Display only the first line of comments

I tried "Display only the first line of comments", but when the first line of comments is displayed in a task title, it does not replace the default title name, "Task", and it is also grayish.

For "Selected text as task title", maybe "Display the first line of typed comments as task title" (i.e., bypassing the automatically stamped date and time--if that becomes an option) would be an even better implementation--it would require fewer mouse clicks from the user .

And somewhat related to task titles, here's a thought on comment titles: to have the first line of typed text in the comment field automatically boldfaced so it'd stand out as a title for comments would also be really helpful, especially when the comment field is maximized, with the task tree out of view.

This is Dan's software and he might or might not implement your suggestions. Anything I say here is just a personal comment based on my own usage.

For making the first line of the comment the actual task title, this can be accomplished with a UDT, and with less effort than selecting, going to a context menu, and selecting an option. With just a tiny bit of code, a UDT can read the comment, extract the first line, then execute a TDL command-line that sets the title with that text. So if you have any programming experience consider that. If not then I might add this to my Nebula UDT (see my sig).

About bolding the text, that implies that all of your comments are Rich and not Plain Text. That may be the case but there's no certainty. I'm thinking there are not only conditions for which you need to be aware, but this is a highly specific request which almost certainly doesn't apply to most other users. This is yet another application for a UDT. For reference it's also possible to do this with my .NET library, which has still not yet been published. If there is some way you can make your request less specific to one user, it might get more support.

Because these proposals are very specific to the way that you work, I suggest using a scripting tool like AHK to create the custom actions and then adding them to TDL as user-defined tools in the preferences. This way they would all appear in the Tools menu as well as on the toolbar.