|
A month maybe for the first dev release.
|
|
|
|
|
Dan,
I am looking forward to this. I have done some research regarding this, and now know that I am looking for 'effort based scheduling.' I think I can get something like I want with just a GANNT chart. Will the plugin be zoomable regarding the time allocated e.g. into the level of hours within a day / out to say a few months?
Best wishes,
Tom Troughton
|
|
|
|
|
Tom Troughton wrote: Will the plugin be zoomable regarding the time allocated Yes, but I haven't got it down to days or hours yet though this is the intention.
|
|
|
|
|
Great, and thank you.
Best wishes,
Tom
|
|
|
|
|
|
Hi Dan,
As you may have guessed from my question, I am currently swamped and taking on water - however the tide has stopped rising. I am installing it this weekend, and will get back to you with comments Monday or Tuesday. I am really looking forward to see what you've done.
Best wishes, Tom
|
|
|
|
|
|
First off, ToDoList is a great tool, so thanks! It is even cooler nowadays, when you can put the files on something like SkyDrive.
Now to the daylight savings issue: After the daylight savings time change over in spring or fall, ToDoList will have a file change notification for every open list. The notification is fine for real changes, but it would be cool if it looked at the system setting and notice that the hour has changed by exactly an hour on a certain day in the fall or spring (or if change detection were based on something like date, then size and/or hash of the file, to avoid false positives). Is there already a setting for this that I don't know about?
|
|
|
|
|
Matt Gerrans wrote: Is there already a setting for this that I don't know about? No.
The best solution is probably for me to store the file times in UTC so that we can avoid the daylight saving issue altogether.
|
|
|
|
|
I have TDL set to run at startup of Windows Vista SP2. Moments ago, following a restart, an error dialog appeared. The window title bar read, “Web Update Wizard.” The dialog text read, “Warning - invalid syntax in block of Web Update Wizard script. Please
see WebUpdateSvc.log for more information.”
I had no idea what application had caused the error, but I did a search of my disks with Everything, and found a file with a name similar to “WebUpdateSvc.log” in the directory where ToDoList is installed: “WebUpdateSvc2.log.” The file identified in the dialog message (“WebUpdateSvc.log”) no longer exists in my system.
The text in WebUpdateSvc2.log created at about the time the error dialog was generated consists of a number of lines starting with the string: “Syntax error in 'www.abstractspoon.com/todolist_update.txt'. The rest of each line describes the syntax error.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '"http://www.w3.org/TR/html4/strict.dtd"> -->' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<HTML>' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<HEAD>' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<META HTTP-EQUIV="Refresh" CONTENT="0.1">' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<META HTTP-EQUIV="Pragma" CONTENT="no-cache">' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<META HTTP-EQUIV="Expires" CONTENT="-1">' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<TITLE></TITLE>' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '</HEAD>' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '<BODY><P></BODY>' is not a valid Web Update Wizard keyword.
03/12/13 03:03:15 Syntax error in 'www.abstractspoon.com/todolist_update.txt', block []. '</HTML>' is not a valid Web Update Wizard keyword.
When I went to review “todolist_update.txt,” however, I again found no such file on my system. Neither were there any TXT files in the folder with ToDoList.exe.
Thinking the identified file had simply been accidentally deleted from the folder, I downloaded the current version archive. When I unpacked it, however, I found no file named “todolist_update.txt,” or anything similar. All of the files in the current version archive were already in the folder from which I run TDL.
Rather than simply dismissing the error dialog, I decided to document and report the error because of the fact that it contained references to two currently non-existent files, and thus seemed like it could be a result of old code not having been removed. Depending where in the TDL code these messages came from, this strange behavior might point toward, or be associated with, more serious problems.
|
|
|
|
|
After posting my report about this problem, I restarted my system to see if it would recur. It did not.
I then checked the Windows Event Logs, and found no errors or anything unusual about the boot process during which the error had occurred, which took place about 2:58 AM on 3/12/13. The info recorded about that boot is almost identical to that recorded for the one that started about 3:53 AM, after I posted my report, and did not reproduce the error involving the Web Update Wizard.
It’s hard to imagine why this error would have appeared now. It would make sense if it appeared just after an update had completed, but it’s been days since the last TDL update, and the system has been restarted many times since then.
|
|
|
|
|
As far as I know this was a transient server glitch that delivered a web page rather than the update script.
|
|
|
|
|
|
The same problem, displaying the same message, happened again this morning when TDL started.
If you'd like, I can continue to let you know when this happens, in case recurrence might indicate that the problem is not "transient." I can also let you know if any new messages are presented under similar circumstances.
On the other hand, I can also ignore all similar incidents. Pleas let me know what you'd prefer.
|
|
|
|
|
|
|
Using Version 6.6.4 on Vista SP2, I have encountered a very serious problem. Early on 3/10, I imported a list of tasks from CSV to create a new tasklist, and saved it as a TDL file. Over the next 7 hours, I modified the file extensively, and made multiple saves of the file. Among the changes was to create reminders for dozens of items in the list.
I then left the computer for many hours, and returned about 10 pm on 3/10. No one else had access to the computer during that time, and there had been no system crash or other problem. I expected that some of the reminders that I had scheduled would have been triggered in the interim, but saw no boxes on the screen. I opened up TDL from the system tray, and saw that none of the list items any longer showed the reminder symbol in that column. I tried opening up earlier versions of the TDL file, and found that none of them displayed the reminder symbol for any items on the list.
I then created a reminder for one item, and saved the TDL file. Next, I used WinMerge to compare the contents of the TDL files before and after that change. Even though the reminder symbol was visible on screen, WinMerge found no differences between the TDL files. So, unless the reminder information is stored elsewhere, it was never recorded on disk by the program, although the memory image evidently was changed to cause the reminder symbol to appear on screen.
I'd like to think that all my work is still safe somewhere, and is just not being displayed, but I can't see how that could be. Please help.
|
|
|
|
|
The reminders are stored in the ini file not the tasklist.
And before we starting shouting about major bugs perhaps we should investigate it some more.
|
|
|
|
|
I didn't mean to upset you about this. You have a wonderful product, and do great work. However, for the reasons I shall explain, I thought my subject line was warranted relative to the seriousness of the problem.
Regardless of where the reminder information is stored, I believe it is a "major bug" that it should ever become lost or corrupted, and disappear from the interface. It is the fact it got corrupted or lost, rather than the possibility that it can be restored, that led me to choose my subject line.
At this moment, the single reminder I created (as described previously) does not appear in the UI . ToDoList.ini seems to explain why that is the case. [Please note that I have created several tasklists, and the one where the problem appeared is, itself, named "Reminders," simply because that's why the tasks it contains were grouped together.}
The relevant lines are as follows:
[FileStates\REMINDERS.tdl\Reminders]
NumReminders=1
[FileStates\REMINDERS.tdl\Reminders\Reminder0]
Enabled=0
FromWhen=1
LeadIn=0.000000
Relative=1
SoundFile=C:\UTILITIES\ToDoList\System Scheduler default sound (louder than Windows default scheme)_ding.wav
TaskID=10
The first section heading correctly shows the total number of reminders that should appear at this point. The second section has details about it, and the task to which it relates. The indication that it is not enabled is incorrect, however, insofar as it has not been “disabled” by my intervention since it was created.
The concept of “enabled” in that line confuses me. I think that having an option to disable a reminder could be valuable, because it implies the possibility that it could later be re-enabled. However, the only two actions related to reminders that are available on the right-click menu for a task are “set” or “clear.” There is no option there to “disable” a reminder. I can see that an “enabled” state could arise when the reminder is created, but if the user can’t select it, how does the state for a task become disabled? Furthermore, to be really useful, if the INI file section is retained when a task is disabled, shouldn’t the section also retain the time info, like that shown in the following section (from another tasklist) for an “enabled” task?
[FileStates\ToDoList_JEFF'S MASTER LIST_all projects and tasks.xml\Reminders\Reminder0]
AbsoluteDate=41183.811111
Enabled=1
Relative=0
SoundFile=C:\UTILITIES\ToDoList\System Scheduler default sound (louder than Windows default scheme)_ding.wav
TaskID=194
Finally, is it correct to assume that sections like these are created when the reminder is “set,” and disappear when they are “cleared?”
As I have examined the INI file, I have come up with an idea that would provide a root cause accounting for the symptoms I’ve experienced. The idea relates to when, or if, the INI file is being saved to disk. I had assumed that it was backed up by AutoSave at the same time, and to the same place, as the TDL file. A search of my hard disk, however, indicates that this is not the case. Only one copy of ToDoList.ini exists.
If the reminder info is added to the memory image of the INI file during program operations, but that image is not regularly saved to disk, then all the reminder info created since the last save would be wiped out if the program crashed. The same result would occur if the info is not being saved to disk when the program exits. Since I created all my reminders during one session, either of those possibilities would account for the total loss I experienced.
Another factor pointing to a problem with saving the INI image to disk as a cause for these problems is the fact that I manually clicked the “save” button on the toolbar several times during that session. If that had resulted in the INI file being saved to disk, I would not have lost all my work.
Please let me know what is supposed to happen with this “enabled/disabled” attribute, and with saving the INI file. Then we can see if that is actually happening now.
|
|
|
|
|
I just performed several experiments that bear on my theory.
I added 3 more reminders to the problematic tasklist. None of those actions caused the “save” button on the toolbar to light up. Adding a task caused it to light up. This indicates to me that even manual “saves” only save the TDL file, and not the INI file. Is that supposed to work that way?
Next, I checked the modified date on the INI file. It was not changed, indicating that the changes that should have been caused by the addition of 3 new reminder sections had not been saved.
Next, I closed ToDoList, and confirmed that its process had exited. I then checked the INI file again, and found that its modified date had still not changed, indicating that new info still had not been added.
However, when I opened TDL again, found that the three new reminders still showed for the tasks. The modified date of the INI file still had not changed. Manually checking the INI file contents showed no new sections for Reminder1, Reminder2, etc.
I don’t understand the last result. If the UI displays what is in the INI file, the reminders should have disappeared, since the memory image had been deleted, and the hard disk image had not been updated.
Any thoughts?
|
|
|
|
|
What Windows OS are you using and where is ToDoList.exe located?
modified 11-Mar-13 23:18pm.
|
|
|
|
|
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.
|
|
|
|
|