|
|
Comments and Discussions
|
|
 |
|
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.
|
|
|
|
|
|
|
 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 | 13,024,757 |
| Downloads | 225,331 |
| Bookmarked | 2,924 times |
|
|
Submit an article or tip
Post your Blog
