|
|
Comments and Discussions
|
|
 |
|
I’m running TDL under Windows Vista SP2. Since I began using it, ToDoList.exe has always been stored at the location specified by this path: C:\UTILITIES\ToDoList\ToDoList.exe. All the related TDL files are stored in that same folder.
|
|
|
|
|
While checking something else, I just discovered a situation indicating that the report of my experiments in my last post was wrong in two important parts.
My statements about the lack of changes to the modified date of the INI file were based on what I saw in Everything, which is supposed to (and always had, so far as I’m aware) report any file activity in the NTFS by querying the USN Change Journal. However, when I looked at the information about the INI file itself, in Explorer, I found that the modified date was showing as changed, although Everything did not report that change.
Secondly, my statements about the lack of changes to the content of the file itself were incorrect. I was looking at the INI file as a text file using EditPad. It does not lock files when it has them open, but is designed to display a notice that the file has changed on disk when that happens. I thought that notification was persistent, but apparently it disappears after a brief time, so that when I came back to look at the file after each stage of the experiment, I had no indication that anything had changed.
Repeating the experiments, and looking directly at the INI file itself, I find that it does update on disk when reminders are added, but that this happens only when TDL itself exits. Is that correct?
With that established, I then reopened TDL, and “cleared” one of the reminders I had just set. After exiting TDL, the INI file still showed the section for that reminder, but now it was showing as disabled, instead of the entire section having been removed. That seems like a design flaw. While a choice for the user to disable a reminder might be useful, it seems like not “clearing” the reminder information when it is cleared by the user just leads to the accumulation of needless, obsolete data in the INI file. What do you think?
At this point, it seems like we can say that the program is saving the INI file properly when it exits, but not any other time. I think that behavior needs to be changed. On my system, TDL list is loaded with Windows, and almost never closed by me. 99% of the time, the TDL process is still open when I restart or close Windows, and is shut down by Windows along with all the other processes. That means that 16 – 20 hours might pass every day without any of the changes that should be stored in TDL.ini having been saved. That leaves important TDL data vulnerable to any TDL “crash” or “hang.” which would occur without any of the results of certain types of work performed since the program was opened having been saved to disk.
However, In this particular situation, the Problem Reports and Solutions history doesn’t show any entry for any problems with TDL during the relevant period. Moreover, Windows System Event Log show only one system restart during the relevant period, and no “error” type messages indicating a Windows problem. For that same period, the Application Log show no events related to TDL, and nothing suggesting any type of system crash.
Unfortunately, I don’t think that news gets us any closer to an answer about why TDL didn’t save the INI file properly during the period in question, at least during the restart at 11:04 AM on 3/10. I don’t believe I worked with TDL any further until I discovered the reminders missing about 11 hours later, and began the investigation that led to my initial post.
Any ideas?
|
|
|
|
|
I'll try to have a look tonight and get back to you.
|
|
|
|
|
Thank you. I'm in Los Angeles, which means there is a 17 or 18 hours difference between our time zones. Don't be surprised if I don't get back to you right away.
|
|
|
|
|
Please have a look at the report I just posted with the title "Bug involving the "Web Update Wizard." It's possible the cause of that problem might be related to the cause of the reminders not being saved.
|
|
|
|
|
ps. Not ignoring this issue, just in the middle of upgrading my hard-drives and reinstalling my dev environment.
|
|
|
|
|
|
|
Hi,
Since version 6.6.x the multi-sort option stopped working correctly, if i use the following order:
1. Start Date
2. Due Date
3. Task Name
If i don't use the multi-sort with the dates start/due the multi-sort seams to work, it's this a behavior situation that can be solved with a new config setting or this a bug?
Thanks in advance
|
|
|
|
|
Hi Ricky
Can you send me a trivial tasklist which displays this problem pls?
ps. My simple experiment suggests that it is working correctly.
modified 11-Mar-13 1:33am.
|
|
|
|
|
I've a task list example, but i don't know how to send you the file.
By the way i did some testing and verified that if a create a new task list the multi-sort works well, but if i use my tasklists or copy part of the tasklist to a new tasklist the multi-sort doesn't work. For now and because i really new the sort working i moved back to version 6.5.10 where i've no problem in the sort.
Thanks in advance
|
|
|
|
|
RickyC0 wrote: but i don't know how to send you the file.
My e-ddress is in my signature.
ps. Can you also describe exactly what _you_ expect to see with the sample tasklist?
|
|
|
|
|
why it refers to code project page?
|
|
|
|
|
Works fine for me .... You must be logged in to download.
Where is the problem? 
Pierre
|
|
|
|
|
I made some parent tasks where the inheritance of attributes is enabled. It works fine when creating new tasks.
But when I copy & paste other tasks (tasks which are used as templates) there seem to be no inheritance. Right? Could it be used / defined / enabled?
Pierre
|
|
|
|
|
Strictly speaking attribute inheritance comes into play when a parent attribute is changed. Therefore pasting tasks as subtasks into a parent task probably falls outside this behaviour.
I will consider adding a preference to control this.
|
|
|
|
|
Hi Dan,
Not sure whether this is me not doing things right, but...
I have noticed in the past that the 'Hide Parent Tasks' goes missing from the 'Options' dropdown in the filter bar.
I noticed this quite a while ago, but changed the entry in the 'Show' dropdown a few times and 'Hide Parent Tasks' seemed to return. So I figured the visibility of this option may be clever and affected by what the other filters are doing.
However, it has just happened again, and I can't seem to get it back (short of restarting the application). The thing is, in List view, the parents are hidden, which means the option is in effect - the entry in the dropbox just isn't visible.
Is this a bug, or am I just not up to speed with how this function is supposed to work?
zajchapp
|
|
|
|
|
The option disappears when in list-view if you have selected the preference to 'Always hide parents in list-view'.
|
|
|
|
|
Thanks Dan. However.
I do not have this option checked, yet the situation is described as above (parents are hidden, but the option is not visible in the dropdown - but has been).
PS: Had to go hunting for this preference - shouldn't this preference be under the filtering section?
zajchapp
|
|
|
|
|
zajchapp wrote: shouldn't this preference be under the filtering section?
I didn't think so because it operates outside of filtering.
Any more information you can give me would be appreciated.
|
|
|
|
|
I am not sure what else to tell you...
- The option is not checked in the global preferences.
- I seem to recall setting the Option in the dropdown some time ago for my main tasklist.
- The option does not currently appear in the dropdown, for any of my tasklists. I have restarted and rebooted.
- The Listview does not show parents.
Is there anything else I should be looking for?
zajchapp
|
|
|
|
|
zajchapp wrote: s there anything else I should be looking for?
Not for now. I'll look at it some more.
|
|
|
|
|
Weird thing, if I put the exported html file from tdl in a web server, it is displayed as plain text (weird six bytes in front of a bunch of plain-text html tags, I'm suspecting that is the BOM)
It works when I open the file locally and displays fine. When I put it on a server, it doesn't. I've tried multiple stylesheets. I *know* I've done this before successfully.
I've tried serving it with charset response header, I tried utf-8 and utf-16, it didn't fix it.
Just now, I managed to use a text editor to save it without the BOM as utf8 and now it works.
|
|
|
|
|
tl;dr - can we get an option to turn off the BOM so IIS could display the exported file correctly? thanks
|
|
|
|
|
Before I do that, can you research that this is a known problem with IIS that cannot be resolved another way?
Thx
|
|
|
|
|
|
|
 General  News  Suggestion  Question  Bug  Answer  Joke  Rant  Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
A hierarchical task manager with native XML support for custom reporting.
| Type | Article |
| Licence | Eclipse |
| First Posted | 3 Nov 2003 |
| Views | 15,174,807 |
| Downloads | 228,136 |
| Bookmarked | 2,936 times |
|
|
Submit an article or tip
Post your Blog
