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'

Updating that slightly:Rich Text comments are compressed within the tasklist as CUSTOMCOMMENTS, which is a sub-node of the TASK node. It only appears if there is a comment present, and it is rich text.

As far as I am aware, CUSTOMCOMMENTS is not accessed directly. The stylesheet refers to HTMLCOMMENTS. Refer to my stylesheets (start with a Z).HTMLCOMMENTS is a sub-node of the TASK node, but does not appear in the TDL file. It is generated upon the transformation of the file, from the COMMENTS and CUSTOMCOMMENTS information (I think).Note: If you start TDL (6.7) with -g for logging, the temporary tasklists generated for the transform are saved to C:\Documents and Settings\your_user_name\Local Settings\Temp. Useful for inspection.As mentioned here:ToDoList 6.8.2 Feature Release - An effective and flexible way to keep on top of your tasks[^]

Please also note that Introduction.tdl appears to be out of date (at least in my installation). Comments are still treated as attributes of the task node, rather than a sub-node. Probably opening and saving would sort this out?

@Dan: Can you confirm the above? Also, could you tell me why tasks have both the CUSTOMCOMMENTS and COMMENT subnodes? Is this for legibility or other reasons?zajchap

CUSTOMCOMMENTS is used by the TDL file (read/write)HTMLCOMMENTS is used by the stylesheet to access these rich text comments, presumably using a combination of COMMENTSTYPE and CUSTOMCOMMENTS. If you check the temporary transform file, you will see the created HTMLCOMMENTS tags. How and why it works this way, I am not sure.

CUSTOMCOMMENTS is an 'internal' tag, and cannot be used in 'external' transformations (it is compressed and converted to Base64).

And the reason that HTMLCOMMENTS is not stored permanently is that whilst images embedded within the rich-text comments are wholly stored within the tasklist file (so the tasklist can be moved without worrying about the images), this is not possible in HTML which required an external folder for images. Therefore I decided way back to always auto-generated the HTML on demand and then clean it afterwards.

What's confusing IMO is that in addition to HTMLCOMMENTS, TDL currently also copies the plain-text comments as COMMENTS, for reasons I can't recall, forcing stylesheets to test for both.

So to simplify stylesheet design I would suggest that comments are always rendered to HTMLCOMMENTS even if they are plain text, so that we don't need stylesheets to test for both.

I can also make sure that exporting to .tdl will also render HTMLCOMMENTS, but be aware that the exported .tdl file will necessarily also include COMMENTS and CUSTOMCOMMENTS in case the user subsequently needs/wants to re-import the file.

In essence, bringing all the goodness the GUI would when run manually.

The tricky bit will be parameters.

I assume this would end up being commandline access to the user defined tools (in order to do parameters). [In the past this probably would have been done via DDE. Don't know if that's still around these days.]

This thread started out as a request for an algorithm to extract CUSTOMCOMMENTS entered by the user, via stylesheet, which would permit batch processing. TDL is encouraging such external processing, e.g. msxsl.

(If I read zajchapp's post correctly), instead, CUSTOMCOMMENTS are transformed into HTMLCOMMENTS upon export by TDL. Yet that export is not present using the encouraged msxsl.

Nor is there a way to batch that export. The code is present to do so, the work has been done, but will not be exposed.

Users spend some time on their lists, including formatting comments.

How can (what algorithm) that infomation be revealed (published to team mates, as no man is an island) in an automated fashion?

.&gt CUSTOMCOMMENTS is an 'internal' tag, and cannot be used in 'external' transformations (it is compressed and converted to Base64).

That's fine, all I asked was for a sample as to how to process it. Moreover, I'm not overly concerned if it's a non-working sample, it's the methodology that's the mystery.e.g. [this is going to be REALLY wrong, think pseudo-code or something] <p>{xsl:text "decompress(decode base64,<xsl:value select="CUSTOMCOMMENTS"/>)"/></p>"

Finding 'xsl' functionality to do it can be left as an exercise for the reader.

&gt And the reason that HTMLCOMMENTS is not stored permanently ...

I thought the problem of binary data within text files was a long solved problem from nntp days, even within HTML. And with that, 'inline' images within HTML are ... not unusual. No?

&gt So to simplify stylesheet design I would suggest that comments are always rendered to HTMLCOMMENTS even if they are plain text, so that we don't need stylesheets to test for both.

I'm not so sure - wouldn't doing so take away the stylesheet's author's control over formatting? Text would blow up in surface space due to the inanities of the space taken up by <p>, et al?(Isn't it just an attribute?)

One of the things I don't understand is why there isn't only the COMMENTS tag, and the type of comment specified by attribute.

I do get the need for stripped / plain text AS WELL - experience tells me one way or the other you'll always be wrong, they'll want 'the other one', and just easier to have both in the first place.

I would have thought (and I'm probably revealing my ignorance here), that a wee bit of stylesheet code, <xsl myvarname="<xsl value of: HTMLCOMMENTS>", gets the finicky bits into a variable and the rest becomes an exercise for the reader. e.g. Wrap the variable up within a <PRE> or something, and we all get on with our day. If something more sophisticated were desired, that would be up to the stylesheet author. TDL exposed the data, and more can't reasonably be asked of it.

&gt I can also make sure that exporting to .tdl will also render HTMLCOMMENTS, but be aware that the exported .tdl file will necessarily also include COMMENTS and CUSTOMCOMMENTS in case the user subsequently needs/wants to re-import the file.

I don't think it much matters how you do it, it will likely all be straightforward. The only thing that really matters is that it be documented so we can find / follow it. Presumably in the .xsd or accompanying .txt file.

One problem I can see here is, there's no actual reason why you can't have multiple COMMENTS per TASK. (Other than the GUI interface doesn't facilitate it.) Arguably, that's how things should be written, anyways (?), the end of a COMMENT indicating a line break.

I can easily see how the multiple forms of comments could come about ... having had comments for a while, then having implementing RTF comments, presents ... issues. Let alone, suppose I don't initially have RTF comments turned on, then later do so. What to do with the comments already in the file? And what if I later turn them off? <ICK/> <-- Note: New tag!

Surely this is all a solved problem somwehere. How does Freemind handle such? It's all GPL'ed, isn't it?.

When one returns to the normal view from the "Maximize Comments" view, the tasklist is scrolled all the way to the top, with the selected task dropping out of view (unless it happens to be a task near the top of the task tree). In a long list of tasks and subtasks, and without a "Go to Task" command on the comment field's context menu, it may take quite a bit of scrolling to spot that task again. Is there a way to make the selected task stay put in this situation?

As part of some testing, I took Introduction.tdl and exported it, and saved it under a different name

The copy is a different size than the original, as is the export. The export and copy are exact copies. (Binary.)

Looking at the guts, the original is still in the <TASK COLUMN= format, while the saved is in the

<TASK ... <COLUMN> ...

format.

Could the sample tasklists be updated please.

To some extent, but I'm not yet sure to what extent, this has caused me to chase my tail for a week. e.g. Different outputs, direct transform vs in GUI transform, producing different results. Different (unbeknownst) inputs, so of course different outputs.

Each task has also gained

<PERSON/><CATEGORY/><DEPENDS/>

lines. Don't think that has mattered to me, yet.

But it was quite startling to realize my baseline (Introdution.tdl) wasn't in a current standard / baseline format.

In TaskTree view, the position column will not be updated when a task other than the one in the first row is moved to the first row. Is it a bug?Btw, could someone please tell me when the position column would be useful?

If not, if I cross reference and update tdlschemadef to the .xsd, is that useful?

Haven't done a deep dive / forum search on this yet, but how would I check out / post updates on this? Are there explanatory links around to the specifics of the tdl code maintenance / contribution ecosystem?

(I do not have, nor will I ever, visual studio. Doesn't mean I can't contribute text files. [It's noted in another thread that vs express versions do not include mfc, so express versions will never be useful with regard to TDL. If I understand that all correctly.])

So, tdlschemadef.h, I'm guessing, will always contain the at most list of fields?

Not saying they'll all be used, let alone all the time, but no fields / attributes will appear that aren't in that header?

Confirm?

So, if I cross reference and update tdlschemadef.h to the .xsd, is that useful?

I'm assuming any 'report writers' like iReports needs to a schema to know what fields to offer. Which would take the ability to make stylesheets out of the realm of programmers only. (And have the potential to make even their lives easier - particularly with respect to calculated fields and group / summary totals.) Would be nice to know how to make iReports work, if anyone has tried.

i.e. If I go hand edit and submit back to you, is some other maintainer going to load it up in some tool, update it, and lose some of the hand editing in the process? (So I should use the same tool as them in the first place?)

- what's coming to mind is if I, for example, apply comments to closing tags, e.g. </tag><!-- name="mytag" -->, are those comments / hand edits just going to be lost when that app updates the file?

This may not be the right time to beg for another boon (please excuse that language--I've been reading Don Quixote!), but rashness got the better of me --could you please consider including a new command in TDL's list of keyboard shortcuts: Toggle Expanding and Collapsing All Tasks (http://www.codeproject.com/Messages/4719191/Re-AutoHotkey-scripts-for-TDL.aspx)?

Just to avoid remembering separate keypresses for 'expand' and 'collapse'? Poke tongue |

Well--yea, that, and...because I'm kind of attacted to the idea of making one command do the work of two, following the principle of economy of resources, and...and...oh, right, now that Jochen has so kindly taught me how to make clickable command buttons with AutoHotkey scripts, I'm probably going to script away like crazy (not a la Don Quixote--not to worry), so that before you know it, I won't have room left on the toolbar to put any more buttons--so we could chalk this third reason up to "space conservation"!

Hi Dan, you do not know in what state the topic was. I do not know if you could see some interesting "UI" I sent you (I left links).I was recently watching the "LeaderTask" program. I guess you know it. (but there is a renewed version)http://www.youtube.com/watch?v=5eUYXikPe7Q[^]I think it is a very good example of a "User Interface" simple and clear.Several things have been well thought about the functionality.

Makes you want to explore it more. (Not me, much, the average user.) What's here? What is this beastie? Anything here of use to me?(A little reading, see 'cloud', and 'subscription' - looked deeply enough to determine that it was indeed a subscription, and ... bye now!)

But I thank the OP, it is a good example / observation / response to the question posed.

The OP got me to click the link, and I spent more than 8 seconds there. I checked out whatever screen shot type views I could find. If I had seen more of what I was looking for in the functionality I would have continued to investigate.

For contrast, I went to abstractspoon.com. On the sides I see 6.5. Below I see 6.7. I see a date of Latest News - 17 Jul 2013. So, I'm not inclined to stick around and look deeper.

So I guess 'prettiness' burps out to being able to show it.

Don't mean to morph your question into a web site comparison, but I do think the concepts the exercise exposes applies to your question.

Prettiness (non-'ugliness'?), evidently, include the environment and ecosystem, not just the app itself. Including how do you attract enough attention to have them step through the door and take it for a spin.