|
|
Comments and Discussions
|
|
 |

|
TCP_JM wrote: 1.) If I start ToDoList I always get the 'open tasklist' message: 'The file C:\...\CH_3.tdl is currently held under source control....' It would be very good if this could be disabled. The fact that the file is under source control can be seen by looking at the icon on the tasklist tab
This is behaviour from TDL and not from my aggregator. I can disable source control (and rely on the read-only property that I set - but you will get a message for this as well, unless you change the setting). I can disable both source control and read-only - but then you can edit the target file and lose all your edits when the next sync happens. Personally I am more willing to accept this message than accidentally editing this file and losing my edits, but I think I will remove the source control and keep the read-only flag, and then rely on the setting being changed.
TCP_JM wrote: 2.) The other message "'The file C:\...\CH_3.tdl has been modified outside of ToDoList. Would you like to reload it?" It seems not to be possible to disable this in the ToDoList preferences. It would be very good if this could be disabled, too.
Under multiple users - what is your settings for "If a tasklists' timestamp changes" - mine is set to "reload without asking" and I do not get any messages.
TCP_JM wrote: 3.) What I really like is that the tasks in CH_3.tdl are linked (dependency) to the original tasks. This makes it very easy to work on the tasks in different lists.
[There is a little 'but': I have no idea whether it's possible or not, but it would be great to work on the tasks in list CH_3.tdl and the changes will be made in list 'CH_1.tdl' and 'CH_2.tdl'].
With regards to your but - I agree (and here comes my but) but it is next to impossible. There are too many situations where a data loss can occur (for example having an unsaved local file open, making a change to the aggregate file - now you have two versions of the file - one of which is going to be lost).
TCP_JM wrote: 4.) The parent task's names in CH_3.tdl
These names are representing the the path and the name of the original files. As a result of that the 'parent task's names' can get very long e.g. C:\Organisation\Tasks_Appointments_Notes\ToDoList\_Versions\_Testversions\Capital_H\Merge_Script\CH_1.tdl. Just an example. Paths like that are not common, but it may be an idea to shorten the 'parent task's names' to just the file name.
For the next release I want to use (1) project name (2) file name only (without path). At the moment I am using the parent title to set up the file links, so it is less trivial than it should be! (but not too difficult)
TCP_JM wrote: a) Changes are only made in 'CH_3.tdl' if the original tasklists ('CH_1.tdl' and 'CH_2.tdl') are saved after changes that are made there. Understandable but a little tricky. I'm not saving a tasklist after every little change.
Unfortunately outside my control, unless I call a "save all" from time to time. My settings are set to auto save quite regularly (when losing focus, switching, before tools, and after 1 minute) - but if this is not an option for you this will be a side effect. I (1) cannot extract information from unsaved tasklist and (2) cannot see which tasklists are saved.
TCP_JM wrote: b) Let's assume I change something in list 'CH_1.tdl' and save the list. Your script becomes aware of that immediately. Very good! A little "bug" crept in. If I switch back to 'CH_3.tdl' I cannot see the update of the situation in 'CH_1.tdl'. I can only see it after I use the key 'arrow up' or down. Then suddenly the view gets updated.
Example: mark a task in 'CH_1.tdl' as completed, save the tasklist and switch back to 'CH_1.tdl'. The task is still shown as uncompleted in 'CH_3.tdl'. Now use an arrow key. Now it is shown as completed, too.
One more thing: Sometimes it is like the screen is frozen. Let's say a user deletes a task in list 'CH_1.tdl', saves the list and 'CH_3.tdl' gets updated. It takes some time before the view gets updated visually, too.
The user can move the selection of tasks by using the arrow keys, still sees the deleted task but cannot select the deleted task. And the suddenly it's gone visually too.
This is strange. With most of my tests with *reasonable* tasklists (3 tasklists, 1 on a slow network drive, 2 local, 2 with about a 1000 tasks (including the network one), 1 with about a 100 tasks) it takes about 300-400ms to create the aggregate list (at the moment a traytip should popup displaying the time - I will disable this for the "production" version though).
Now I do all of my manipulation on the TDL file itself, so there should be no redraw issues. What I do not do is force a reload (via the command line), so it might be that the new updated list is not yet loaded (since there is about a 5 second lag before it is reloaded).
I am unable to reproduce the pressing a what key to update but what happens to me is that it does not update until about 5 seconds after making a change (which might explain the freezing process).
I can probably monitor the window title, and force a reload if you have switched to the target tasklist (or if Dan obliges creates a command line option that reloads the tasklist without switching to the tasklist).
TCP_JM wrote: c) I'm not sure if it is the desired result to show tasks in CH_3.tdl that are completed in the original lists. The filter in your script shows 'due tasks + xyz'. If I complete a task in 'CH_1.tdl' this task will still be shown in 'CH_3.tdl'. I was a little astonished at first. I would have expected that 'CH_3.tdl' wouldn't show the task anymore. I expected that the task would disappear.
Reason: I thought that 'CH_3.tdl' would only shows tasks that are uncompleted. That way the amount of tasks shown in this list would get smaller and smaller.
Your way of handling this is good too. This way the user can see what he has already achived.
I have found good solution for me. I just filter 'CH_3.tdl' '( 'B) Incomplete tasks ).
My apologies - that is indeed not the intended behaviour. You will notice in the settings.ini file there is a setting "KeepCompleteTasks" which controls the behaviour with the default being False. However, when I access the "KeepCompleteTasks" variable, I assume that it is a binary variable, however it is a string, which means completed tasks is never removed. Easy fix, will have the correct behaviour in the next release. (and then the user can choose what he wants to see, I prefer not to see completed tasks on a daily basis)
TCP_JM wrote: I have one big tasklist for all my tasks. So I do not need to merge files. But your script could give me a feature that I'm missing in ToDoList. I didn't test this yet but I will. Maybe you can tell me in advance if this can work or not.
I would like to use your script to create a list based on only one list (so it cannot merge two files, it could only work on one file to present in CH_3.tdl.)
It can with the present release. Just change "SourceFilesNum" to 1 and delete "SourceFiles2" in settings.ini (or point SourceFiles2 to a file that does not exist). Is there any other special filters that you want?
I want to use it for a similar use case (almost an error filter if you want). All my tasks must have due dates, and an Allocated To as a minimum. If I filter a tasklist to show empty due dates and "allocated To" fields - I can quickly see tasks that have been entered incorrectly.
Thanks for your comments! I hope this script can add some value to some people
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
A hierarchical task manager with native XML support for custom reporting.
| Type | Article |
| Licence | Eclipse |
| First Posted | 3 Nov 2003 |
| Views | 12,719,851 |
| Downloads | 224,935 |
| Bookmarked | 2,918 times |
|
|