Added preference to use 'Creation Time' when initialising 'Start Date'

Added preference to configure a 'Custom Toolbar'

Added resizability to 'Task Reminders' dialog

Added splitter bar to 'Find Tasks' dialog

Added splitter bar to 'Gantt Chart'

Added support for 'Kanban' tasks to be created directly in selected column

Added support for 'Move > Select Next Task' to 'Gantt Chart'

Added support for 'QuickFind' to 'Gantt Chart'

Added support for high DPI (4K) monitors

Added support for individual 'Custom Attribute' selection in 'Print/Preview' and 'Export/Transform/Email Tasks' dialogs

Added support for inheriting 'Custom Attribute' values from parent task

Added support for title sorting in 'Calendar View'

Added task 'Drag and Drop' support to 'Gantt Chart'

Added task links to 'Stickies' reminders

Added the ability to copy task attributes via the commandline

Added tooltips to 'Task Links' in 'Comments' fields

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, please post to our Google Group.

named "Call Bob" with a priority of 8, the category "Work", a startdate of today, a duedate of 20.12.12, the status "Folder", the icon "Call" and a reminder at 10 o´clock.

The input parser should work optional so not typed attributes should get the default attributes. Also it should be able to interpret/create attributes irrespective of the order of appearance. The user should only have to memorize:

String before first "," is name. Attributes are seperated by "," And the abbreviations for each parameter like p, c, sd, dd...

An explanation of the abbreviations should be displayed within the parser window!
------------------------------------------------------------------------------------------
My second suggestion is to expand the concept of default attributes in the preferences. It should also contain a default icon (name), due date (relative of creation), reminder (relative of...), custom attributes etc.. Actually every attribute should be assignable there!

This for a reason: "Templates for creating tasks"

A set of Default Attributes could be saved under a name like "business calls". A (global?) hotkey could be assigned to each of those sets. Triggering the hotkey TDL would just ask for the taskname and then set all userdefined default attributes of the according set automatically.

Actually, i have a hard time believing that Languages should be a valid reason for not considering an input parser. Especially with a global hotkey it would provide a fast input in every work-situation. In my example i use abbreviations like "p, c, sd". Every user irrespective of the language can use those, no? If you display an explanation of the abbreviatons with the input dialog as i suggested like:

p = priority
c = category
sd = start date

you can translate the explanation (the word right from "=") But i would keep the same abbreviation. Many attributes start with the same letter in different languages anyway!

The abbreviations you use are the same as the command line options; that sounds reasonable.

Your first example however already showed one possible problem: sd20.12.12 or let's make that sd10.11.12.
Why the dots and no hyphens?
And would this be October 11, 2012, 12 November 2010 or 11 November 2012?
Of course you could argue to use the date notation currently in use in TDL.

Anyway, I think something could be said for a key which allows to input a task using the existing code for command line options since this may be a lot easier to implement for Dan.
The date/time issue could perhaps be solved as the command line options too.

But this would not be the same as the request by stream8.
His request could perhaps be covered using +1d, +1w (which could be considered international; not sure if these are translated when using TDL with an other GUI language).

The script shows a little and very simple GUI and the options are (at present):
* task name
* comments
* Due Date
* Start Date
* Creation Date

That is to say I'm using: -nt, -dd, -sd, -md, - cm.

The script creates new tasks only in one specific tasklist, not in the the one that is active.

I have to admit that I somehow "pieced the code together". I was waiting for the big script from Capital_H (that he started to write in April 2012 but couldn't finish for some reason) so I wasn't very motivated to write a script myself in these days (especially because the scripts of Capital_H were always very good IMO). After it was clear that the script from Capital_H would not be delivered I didn't have the time to write an "extended" version myself (not even a much simpler version than the one from Capital_H).

I hope this can be a solution for Alexandra who requested the function in the first place.

As I said in my comment, I was thinking out loud and I sort of seconded the request because I can see the value of it although I don't have an immediate need for it.

Also, I thought it might have been easy; which is of course something only you can decide and I already value all your work highly (I know I can't do support and development at the same time without being angry at those who dare interrupt me ).

At the moment however, the AHK would not be a solution to me for two reasons:
- it assumes (correct me if I'm wrong) the setting 'Allow multiple instances of ToDoList' is OFF because otherwise you would have two modified copies in case you have the TaskList already open;
- I use password protected ToDoLists because I save them on Dropbox (with -x; perhaps this would be a non issue in case the above would not be set).

As I proposed earlier in the previous posts, in order to avoid any mistakes by non-English users there should be an option to change your shortcuts to the functions of the parser (say, you can put any symbol for "Date" starting from intuitive "d" to some symbols in your own language, the function "Date" will stay fixed)
The idea with the templates sounds good, automation will definitely give you a saving grace and facilitate your routine work as you will be using the rules and templates you are used to (offtopic: recently I had a crash for my browser and to restart it completely defaulted. It was horrible, without the addons simple surfing becomes struggle in a boat with a spoon instead of an oar). Luckily I had a backup! What I wanted to say is that we are so much limited by the tools in our everyday life and cannot afford changing them constantly, we are overwhelmed by the increasing number of functions everywhere, yeah, 85 new buttons in a new car, 200 improvements in IOS 5, etc.)
I'd prefer this solution be there in the program though programmer-wise it may be very difficult and add additional complication.

I would like to have Auto %complete by Status.
In Default Task Attributes>Default Statuses, e.g. I assign %complete number to a specific status like "DesignStudy, 20" "OnDesign, 40" and I select "DesignStudy" in Status column then %complete shows 20% completion.
Please consider.

Thinking about this further.
For what it is worth, I'd actually prefer it the other way around. In other words, the status gets set from the % complete. %=0 -> Not started, %>0 -> Started, %=100 -> Completed - but still allow some manual status values to entered (e.g. on hold).
Not sure how it would handle calculated % completes though.
Status for me would be a useful thing to use sometimes, but in practice not useful enough to routinely set...
zajchap