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.1.4 (26 Aug 2017)

Fixed filter selection when names contain brackets

Fixed HTML exporting of '&', '<', '>'

Fixed application window resizing on startup

Fixed file encoding of 'Transformed' tasklists when auto-exporting after saving

Comments and Discussions

I'm, understanding what you want now. You just want to mirror various lists into a single list so that you have a single view rather than multiple tabs which you need to mentally put together.

I think what I suggested earlier will help, assuming you can start doing this from scratch or re-number tasks in existing lists. In each project, set the starting task ID to 10000, 20000, 30000, etc. The first task in the first list will be 10001. That ID will not conflict with any others. So each task list will work on its own. Now when you wish to assemble your mirror you can use the merge script and pull all of those other .tdls into one list, and the IDs won't conflict.

The resulting mirror .tdl should be read-only. You can change anything here but the changes won't be reflected in your other .tdls without further handling. For example you could filter by ID, export, then re-import to the actual .tdl's, being careful to replace everything rather than adding.

I know there are other details worth discussing there, but does that model sound like it will accomplish what you need from a high-level view?

Programmatic manipulation would accomplish everything here but the above solution can get you what you want with the tools that are available.

You just want to mirror various lists into a single list so that you have a single view rather than multiple tabs which you need to mentally put together.

Exactly!

iamstarbuck wrote:

Now when you wish to assemble your mirror you can use the merge script and pull all of those other .tdls into one list, and the IDs won't conflict.

I'm not sure the merge script is needed at all. My understanding is to extend the functionality of 'Paste as Reference' feature from operations within one tasklist to copying and being referred to in another tasklist.
I thought of possible conflict of task IDs but I can only assume that potentially it can be a problem if the task ir referred to a mirror task in another .tdl.

iamstarbuck wrote:

The resulting mirror .tdl should be read-only. You can change anything here but the changes won't be reflected in your other .tdls without further handling.

Not necessarily. I think implementation of the feature in a way I described it above is more than enough.

Per what Dan was saying, I don't think bi-directional cross-file updates is an option.

If a client asked me to do this, and either put a gun to my head or provided a lot of beer and pizza, I could do this with the Library : On saving the "parent" list, the "child" lists would be updated with changes, and on update of the child lists the parent list would be changed. I could even dynamically accommodate the Task ID problem.

So what you're asking is technically possible, just not likely to be built-in.

in the new release the doc says:
"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."

Sorting tasks by Due Date Ascending is IMHO incorrect while Due Date is not set. In this case Due Date is shown as grey "23:59" (looks like it could be that way) and tasks with unset Due Date are shown in the tasklist before the ones with Due Date set. I'd like to see tasks with unset Due Date after the earlier tasks this day.

Bug? Certainly new behavior, anyway: Selecting multiple items disallows me from using the check box to mark them complete. I used to be able to select multiple items in the list view, then hit the check box for one of them, and all would be checked. Now nothing at all happens, and I have to unselect multiple before checking them complete one by one. I can, however, do the reverse, select multiple that are already completed and uncomplete them all with a single click. 7.0.5, list view. Thanks for looking into it.

Not sure, and I'm not seeing it occur with a fresh ini file and the sample task list, but if you use the ini file and task list I sent you for the other problem I was having (jumping scrollbar and refreshing task list upon editing field values), you should be able to see this problem as well when in list view. Just select a task, hit shift and click another one to select a range, and try to check one of the completion boxes. Nothing happens. Thanks.

The problem with checking the completion box on multiple items occurs when more than one recurring task with the option 'Create a new task' is amongst the selected items.

I'm afraid this is 'known issue' for the time being, and I'll add a message box so that at least it's clear.

The issue with the 'jumping' may simply relate to the fact that you are sorting on multiple fields and as you modify those attributes the software is auto-resorting the list items accordingly. Perhaps that's why it is not reproducible with a 'clean' ini file.

Ok, at least the multiple completion issue is in the bug queue somewhere, then. It is new to version 7, if that helps you track it down.

The other one is not, unfortunately, what you're suggesting. I am doing a multi-field sort, but this is occurring when I'm modifying attributes that aren't included in the sort (e.g., the task comments), so it shouldn't be triggering a resort at all. Also, even if it were to refresh the sort, the order hasn't changed (since I haven't modified one of the sorted attributes). It is simply jumping to a different scroll location in an unchanged list-- a location which leaves the currently-selected item scrolled off the top of the screen, which shouldn't happen even if it were a resort-related scrolling issue.

There was/is a bug in the checking of whether or not to resort by a custom attribute that was erroneously re-triggering a sort and then displaying the selected task 'out of sight', which is another issue I'm looking into.

So far I have not been able to reproduce the wayward scroll jumping behavior in 7.0.6. Thanks for the fix. (And the other problem I reported, difficulty marking multiple recurring items complete at once, does now give me a dialog box saying that this isn't currently supported.)

Just a couple of feature requests that I was wondering if they were anywhere on the roadmap and/or if they have any value?

1. Be able to save a filter, with a name, and have a toolbar dropdown list to select a saved filter. In my day to day work I add and update/work on tasks and I use the status to indicate where I'm up to. I have a range of statuses that reflect work in progress, different depending on the type of task. I also have status that reflect tasks ready for a release to stage and another for tasks ready to release to production. So if I could save a filter I could have a work in progress filter, and stage/prod release tasks, so I could quickly see what I'm working on, what's ready to go to Stage and what is ready for Prod, and probably what I have completed. Then I would use the dropdown to switch quickly between the different filters.

2. I would like to have included in the task time log file, or even a separate log file (my preference) the taskid, timestamp, field, old value, and new value when a editable field for a task is changed, including custom attributes. I would find it very useful to see when tasks progressed through the development lifecycle. Sometimes tasks will go to a status of re-development and then re-testing, so I would like to be able to keep an eye on this if this happens, how many times, and how long back in development. So in the log file you might see something like;

TaskId,Timestamp,EdittedField,OldValue,NewValue

688,2015-10-15 10:00:00 AM,Status,Submitted,In Development (task was submitted and is now in development)

or

688,2015-10-15 10:00:00 AM,Category,,Bug (Category was initially blank and was changed to Bug)