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'

Bug report:In this version selecting tasks and trying to email them as a tasklist brings up the "server busy" dialogue. Clicking on retry the dialogue stays for many clicks then eventually disappears. Clicking on switch to process simply brings up the windows start menu. No email is ever created. This worked fine before the latest release. Email client is (or should be) Outlook.NB I have not tried other types of email in the dropdown other than "as a tasklist"Thanks

Thanks for that feedback Pierre. Hmmm. I tried it on my home laptop - the original report was from my work laptop - and on the home machine I got a Windows message saying no mail profile had been set-up - which was incorrect, there is one - and giving me (incorrect) instructions on how to set one up. Good old Microsoft!

I'll have to investigate a bit more. I'd be interested to know if it works or not for others.

I wonder if something has changed in the way TDL accesses the mail profiles but that's speculation at this point. What I can say is that it used to work ok on the work laptop and now doesn't: whilst I can't guarantee nothing else has changed (it's remotely administered) I'm not aware of any update beng rolled out to it and the change in behaviour co-incided with the TDL 6.9 update.

FYI, TDL uses Windows' built-in MAPI support because this easily allows attachments to be specified.

Also, the exact cause of the 'Switch to Server' error is, in my experience, extremely hard to nail down because it is very hard to reproduce reliably by more than one person. ie. it seems to be machine dependent.

Essentially it means that 2 or more parties are both trying to interact with Outlook.exe (the server) at the same time and in such a way that cannot be handled by Windows.

However, since it was working before for you, can you try re-installing 6.8.10 to a clean location and seeing if that still works?

Did the re-install, 6.8.10 worked perfectly. This was on my work laptop.

I checked 6.9 was still failing immediately before trying 6.8.10 to ensure nothing else had changed (6.9 was still failing).

On 6.9 after pressing retry 22 times the dialogue goes away but no email is ever created, nor has this ever been successful on 6.9. I can't get this far on my home machine as mentioned previously but as far as I recall 6.8 worked on on that too. I can do the re-install there as well if you really need me to but the results of the test on the work laptop seem fairly conclusive. Having said that I can't explain why you and Pierre cannot recreate.

hmm just saw this and initially got suspicous - but on closer reading it doesn't look like it would be causing this, and in any event 6.8 works and 6.9 doesn't so it would mean a change in TDL that had triggered the interaction. My home machine doesn't go anywhere near exchange anyway. So I'd say this is a red herring and I only mention it fyi.

I haven't tried the importer. I played around with drag and drop a few years ago as a way of dropping emailed tasks into TDL but I haven't used it for a long while (I stopped because the id becomes invalid in Outlook if the email is moved to a different folder which for my way of working reduced its usefulness).

OfficeMicrosoft Outlook 2010, part of Office Professional Plusfile version 14.0.4761.1000I think it must be 64 bit but no positive proof of that

We run MS Lync, which has a connector into Outlook but I closed that down and it didn't affect the results.

OtherSpeculation again, but could this be profile related? My home laptop has one email profile and TDL 6.9 doesn't seem to recognise it; my work laptop has 2 email profiles, one no longer used - perhaps 6.9 is picking up the wrong profile and that is leading to the non-response it seemd to be detecting? Something is clearly different between 6.8 and 6.9.

Always possible. Is your home profile setup identical to your work setup? Also, could you talk to your IT people to get the orphan profile properly deleted?

snowman1 wrote:

Something is clearly different between 6.8 and 6.9.

I checked the code and nothing related specifically to the sending itself changed between 6.8.10 and 6.9.0. However, there is other outlook related code that did change and therefore could be affecting the working.

ps. I'll add some logging to the next build so that we can see if any of the other Outlook-related code is running when you perform the email.

well well... today I logged my laptop on to the company network via our VPN tunnel (haven't done so in quite a while). I noticed some updates were being applied - as I mentioned the machine is remotely administered.

I had noticed a further article regarding Microsoft's faulty patches that pointed out a further problem with it additional to the ones discussed in the link I posted previously. See here for details.

So after letting the updates complete, I tried emailing again - and it worked. I logged off the company VPN and tried again - yes it still works. Now I don't know what updates have been applied and reverted but maybe all along this has been related to the Microsoft balls-up. In which case I apologise for wasting your time (and mine).

I know there are some updates pending on the home laptop too, I will let those complete tonight and see if the problem goes away there too, I'll keep you posted.

Edit: yep, sure enough, applied the most recent set of updates to the home laptop and it's working fine again. It would still seem that 6.9 was impacted differently to 6.8 by the faulty patches but would appear to have no inherent fault. That's how I would analyse what we have anyway, although there is not concrete proof, it does seem that the patch faults were actually quite wide ranging with some articles only focusing on the worst issues affecting Exchange. Thanks for your help anyway.

The Entry ID changes when an item is moved into another store, for example, from your Inbox to a Microsoft Exchange Server public folder, or from one Personal Folders (.pst) file to another .pst file. Solutions should not depend on the EntryID property to be unique unless items will not be moved.

I can tell you for sure that when moving a MailItem from one Exchange folder to another, or from one PST file to another, that the EntryID changes. However, there are ambiguous notes all over the internet about whether EntryID changes when you move an item from one local PST folder to another. If you copy an email, I believe it preserves the same EntryID, so while that ID is unique to the "store", it's not unique amongst mail items. Perhaps surprisingly, there is no universally unique ID for mail items, though creating one is possible with an Outlook Add-in. As an Outlook developer, I could create mechanisms to create a stable link between TDL to Outlook, but I don't know if there is enough of an audience to support the effort.

If I want to copy just names of tasks I just highlight them and then press Edit->Copy (Ctrl+C).What does 'Edit->Copy As->Text' function stand for? I thought it was used to copy tasks+comments but it's not. Another issue: when a task is copied as text it bears task name, task ID, priority, risk, percent complete, creation date, created by, modified date (only if there are comments), start date, cost, comments (if any) whatever settings you have there, even if you uncheck visibility for all attributes. I tested it with default ini as well, the result is the same. Why so?

Is there any possibility to copy just task title+comments (probably caretted one after another)?

Over the last year we've discussed many kinds of reporting, and Dan has added the Analyse functionality to help as well as making improvements in the timer/clock logging and elsewhere. A couple of my clients are looking for more detailed time reporting. The time analysis generates a summary from the time logged to the .csv. I'm being asked for the kind of data that we log in comments via the Log Task Time dialog, and when we enter comments into a task with ctrl-D for a time-stamp. The .csv data doesn't go into the analysis which is a summary. I'm in a quandary because we have data in two places that needs to be filtered and reported together.

For detail we can just provide clients with the original _Log.csv file and let them do their own analysis. But there are at least two issues there.- First, the comment field for each log line is single-line, and unformatted, and not well suited to record too much about what was going on. The single-line issue can be fixed with a tiny bit of post-processing. Use a regular delimiter like a backtick "`" to indicate a new line, convert the CSV to Excel, change the comment column to multi-line text, and use find/replace to convert all backticks to newlines. This can be automated.- Second, we can only start/stop the clock without a comment, or we can log time afterward with the dialog and put a comment there. We don't have a way to apply a comment to an actively clocked task. I have a UDT which does this and at some point I'll publish it.----One built-in way to handle this might be to have a custom field which is linked to time logging. When you click the icon to start logging time, this field on the task gets cleared. You can then enter text as you do your work. When you turn off the clock, the text is set into the CSV with the logged time and the text is left in the task for reference on the last thing that was done.

Another way to report detail for tasks, not the CSV, would be through a special transform. When I transform my tasks, my XSL extracts off just the first comment line to display in the resulting HTML. So I already have practice parsing that data for specific characters and retrieving a subset of the entire field. But retrieving just the comments within a specific date range is a huge challenge with XSL - and we can't do this with RTF/rich comments. Rather than using transforms for this, I plan to use the new library along with a CSV library to read logged time, and then to check a task for comments with date/time stamp that is within the time range of the logged time - and to do this for plain or rich text. I might encode my task comments to make this easier. But as you can see there is a lot of work here.

So as you see, there are various challenges and some solutions which I plan to implement for myself I'm hoping we can continue to discuss these topics over time, toward proposing enhancements to be built-in to TDL by Dan, toward new XSL transformations, and/or toward new UDTs or post-processors which can come from the user community so that Dan doesn't need to do anything to the core.

I think this is exactly the sort of opportunity that your library would be well-suited to solve.

I'm envisaging an entire app dedicated to producing advanced reporting, that could feasibly be a saleable product. This would not just provide functionality for choosing what info is reported but also provide support for its visual styling (ie it would supplant the painful process of XSL styling).

1) Using the library for new external apps.2) Seeing what people do now with the tools we have.3) Seeing what's possible or desirable within the foreseeable future with TDL core.

To add to the assortment of reporting options: Sure we/I/someone could create a complete reporting package outside of TDL core. Another option available now would be to get more creative with the transformations. Rather than rendering HTML, render SQL queries which will generate a new database. Then use standard reporting tools against that data store. That opens a world of possibilities. And yes, as you say, XSL is painful, so if people can wait for the library then perhaps we/I/someone can create a RDBMS bridge, perhaps with MySQL or Sqlite or SqlServer Express. Then a database export could be as simple as one toolbar click of a UDT.

But for my immediate purposes I'm really curious about how to solve the problem of relating .csv data to .tdl data. Yeah, I'll write my own because we now have new tools. I'm just wondering what else we can do.

Hi dang!Great improvements! Congrats!I'd like to report a strange behavior.If you have a small number of items at 'AllocatedTo', just need to click to select, it's fine, but if you have enough items to force scrollbar to be shown, the first click will put that item at the top of view and then I need to click a second time to select (sorry, couldn't test in others comboxes).

I'd like to include one more info...Please follow these steps:- Create new entry;- Click 'Start Clock';- Open the 'AllocatedTo' combo and select any item WITHOUT losting the focus;I'll see the when "time spent" is updating, the combobox is closed and no item remains selected...If I lost the focus from the combo before 'time spent' update, the selected item is set.

FYI, I added 'wiki:' as a recognised protocol in response to a user request, though I'm so far unable to locate that request.

One solution is just to remove it but that still leaves the question of what caused the crash, which I can't yet reproduce, so any pattern that you can observe in triggering the crash rather than the message box I would appreciate.

1. Type "wiki:" into comments section.2. After the text turns into a hyperlink, right-click on the link, and select "Open Url:wiki".

That will crash TDL. You can see this demonstrated in my screencast at the beginning of this thread.

If you just click on the "Wiki:" link you will get the message, "The selected file could not be opened. Please check that the file exists and that there is an application registered for opening the selected file type."

I've got a tasklist with, say, 4 attributes (Category, Tags, Cost, Title).When I try to transform/print the tasklist with these columns the chosen stylesheet predefines visible attributes (f.i. for Z_SimpleReport.xsl only title and category are visible, cost and tags are not there).

Is there a generic stylesheet to transform/print exactly what I have on my screen (tree view)?P.S. Any user experience is highly welcomed P.P.S. I do know that for printing using a stylesheet can be avoided with different styles but the issue stays the same (see above).

I have a lot of experience with various technologies. But I've never been a stud with XSL. I've learned everything I know by spending time in the TDL .xsl files, then googling on how the features work, and googling more to find out how to do new things that I didn't find in the samples.

It's my opinion that this is a perfect opportunity for someone to learn XSL using a lot of fine examples, with data that we all value, and with a good amount of motivation to make it all happen. The result of efforts will be rewarding. What more could someone ask, except to be paid for the time?

You won't be able to find a pre-defined stylesheet that's perfect for your needs. You'll only find one that's adequate and acceptable. To get anything better, copy an existing file and start editing.

To see tags, look in the sheets Z_SimpleReport.xsl and Z_TimeSpentReport.xsl. You'll see that the code for category is similar to tags. Cost is just another field. I do not find the text "cost" in any of the existing style sheets - the field might have been added after the sheets were added to the package. Try @COST. For any field, just search the Stylesheets folder for examples using the data that you're interested in. When in doubt, see what happens when you use @name, using the node name from the .tdl XML file.

I'd like to publicly thank @Zajchapp and others for their valuable contributions to those sheets which have helped me a great deal to learn XSL and to produce attractive reports.

Thanks. I too am no expert in this area, and have learned what I know of xsl by messing around with stylesheets build by others previously, the tdl files themselves, and w3schools website.

iamstarbuck wrote:

To see tags,

A better way to find the actual attribute or tag name is to save a simple tasklist with the attributes you want, then open the tdl file in a text editor and browse the file. It is usually fairly obvious what you are looking for.

FYI: I did try to put a variety of options into the stylesheets I built, to allow for some customisation. However, these are effectively hidden, so only the keen will find the options.

Hi, If you just want a stylesheet based on Z_simplereport.xsl, or Z_detailedreport.xsl with some different attributes, then I could do that pretty quickly for you. The reason I haven't added COST, is that I have never needed it myself... I guess it could be useful to put in a whole heap more attributes into Z_simplereport.xsl, with the ability to switch these on and off. Perhaps something for me to do over the holidays

If you wanted to modify Z_simplereport.xsl yourself, this can be done in a text editor. The TAG information can be shown, by changing row 67 from =0 to =1. COST is not currently supported, but you could add the following code in at row 423 (after the block dealing with status):