|
_BS_ wrote: > once the classes are complete they don't need the xsd anymore.
I suspect this isn't true - it presumes a static schema. The schema will be a living, breathing, thing, and you're not going to know ahead of time when / what has changed. e.g. I believe Dan has or will finish implementing task/meta elements, and hopefully todolist/custom_meta (or whatever he calls it) elements. What I mean is that the process consists of translating a .xsd file to code, and then updating the wrapper to conform to the latest version. The resulting wrapper is then compiled to a DLL which will read/write XML files which have the same schema version. There is no dynamic schema reference, the .xsd is not required at runtime.
_BS_ wrote: > it will have to stop working to avoid trashing new data.
So, now before using a new version of TDL, users using your stuff will have to wait for you to update? What if you take a holiday? The beauty of FOSS is that one doesn't need to wait for some individual to maintain code. If you know enough to update TDL then you should also know that your other FOSS that integrates with TDL is going to need related updates. You simply don't upgrade until your addons are ready. Let me be clear here: This is the way ALL addon/module/extensions software works on the internet. This is not unique. This is the way it works with Drupal, WordPress, Joomla, and just about any other FOSS package. This is the way web services work. This is the way plugins work for MS Office and your other desktop apps.
_BS_ wrote: > It's my hope that other developers will want to build apps from this where they cannot with C++, and that this might help to build the ecosystem around TDL itself.
Isn't this almost chicken and egg? Wouldn't it be easier to 'give it up' and rewrite TDL in C#, 'strongly' typed (strictly dd adherent) in the first place, and put it up in github, avoiding chicken and egg entirely, and developers can contribute to the root codebase? Feel free to re-write TDL. The code is on this page. Until that happens, Dan will continue to write in C++ and those of us who cannot contribute to his code base can make use of the built-in extensibility. (For the record I can read C++ and am checking the code as a part of my development, but I don't write C++ from scratch.)
_BS_ wrote: All I'm thinking here is for the effort involved, both ways will be about the same amount of work I'm guessing, and this latter significantly enriches the ecosystem. My effort is just to build a library to read/write data. There is no functionality implied here. When this is done, anyone can use the library to build apps. I'm not going in that direction. Your questions imply a re-write of TDL. That's WAY beyond the scope of this library project.
_BS_ wrote: > he already knows that can happen with XML apps
And part of my point is Dan's already stated wish that he had never heard of XML in the first place. This is a path to refactor that. Well, the XML and XSD are a "quick" way of getting all of the fields for the initial code generation. The current fact is that the data is in XML right now. Until that changes we're stuck with it. I just need a nice way to read XML, parse that into strongly typed classes (a tasklist and a collection of nested tasks) and then to re-serialize the data back to XML .. without breaking the .tdl file. I don't really care what the mechanism is but I'd really like to avoid manual XML document manipulation via .NET classes. Bottom line on that is that we work with what exists now. I'm not going to ask Dan to re-write the datastore. The whole point here is to get more mileage from TDL without putting the entire burden on him.
_BS_ wrote: > this library will just need to be updated to follow along with whatever he's doing, and I trust his changes are Evolutionary, not Revolutionary.
Without offense to Dan, he's already shown that he doesn't / isn't interested in applying things cross-app cohesively, or the xsd would always be current. Let alone the change from comment attributes to elements - you can pick the term, whether it's evolutionary or revolutionary. Again, I'm working with the conditions that exist.
_BS_ wrote: > now that we have strongly typed classes
But unless I'm misunderstanding something, we don't, nor ever will. You will always be dependent upon Dan so doing. And he has demonstrated, for the purposes of his own app's evolution, he's going to create new attributes and elements willy nilly as suits his purposes. Without updating or adhering to any published xsd, and quite probably without documentation, change reports, or notification, to you. Feel free to make decisions based on those assertions. As to "we don't, nor ever will", I have code here that speaks to the contrary.
In response to your other comments, I'll just reiterate: I'm working with the conditions that exist, I'm not asking Dan to do anything new, and what comes from this should be a number of new options for those who decide to make use of it.
Feel free to not use the code for all of the reasons you've cited. This might be a dismal failure in concept or implementation. If so, I'll just go back to the thousand other projects that I need to work on. I just see that Dan has busted his hump for over a decade with hardly any code contributions to support his effort, and I'm just trying to give back in a way that agrees with his patterns and preferences as much as his code.
How about this - can we shift directions a bit to talk about how this can be used instead of all the reasons why it shouldn't exist? I mean, we've tried the condition of tools like this not existing, and we've done that for a decade. Now let's try something different.
|
|
|
|
|
I hear you.
Please understand, all I have been saying is that for the amount of effort you're going to expend, and need of Dan (e.g. to ensure strict adherence to the xsd of the moment), applying that effort in a different direction is likely to provide greater returns to a greater audience. Something Dan has said he would like to see.
Ran than Dan do all the work, as you say, let's create an environment in which we can all help him in the 'rewrite'.
e.g. If you're going to do the work of data in/out, you've just completed a non-trivial portion of any rewrite - and eliminated any need to keep anything in sync, it will inherently already be in sync. If that data is in something like PostgreSQL, then strong typing is inherent to that vehicle - the code won't have to worry about making sure all i's are dotted and t's crossed, the database won't let you write non-adhering data in the first place - you may have to fix some code in a specific place for a specific field, but you'll have confidence that you won't be breaking something else. And if you do, it will be immediately noticeable when records fail to write. Data integrity will be maintained throughout, and there will be less of a need to write remediating code.
But I do get what you're saying. Today is today, and you're scratching an itch because you have a particular urge to solve a particular problem today because it's impacting you.
|
|
|
|
|
Example of application.
Skype from colleague after I introduced him to ToDoList:
"If I give you a RESTful service you can integrate it to that thing?"
Me: "yeah"
I wouldn't have been able to say that last week...
If we toss around some ideas about how we can use ToDoList data, both reading and writing our TDL data, then we can plant the seed for anyone who wants to write apps against the library later.
|
|
|
|
|
That would be great. Example code always stimulates me to consider other possibilities.
|
|
|
|
|
Sure, here are some examples:
1) Touched on in the related discussion: Reporting.
Many applications operate on a RDBMS, whether MySql, SQL Server, Oracle, or Sqlite for Android. Most reporting apps do not have a driver for XML, and those that do require a schema (which as discussed, I'll create a new schema as a by-product of this effort).
The library consists of strongly typed classes for app development but I will also add a DataTable interface for ADO.NET. With this it will be easy for someone to extract data from a .tdl, and push it into a RDBMS table for subsequent reporting - a near-line / off-line datastore. Then any reporting tool of choice can be used to operate on the data. I will not be adding exports to specific databases unless I need them. That exercise will be left to anyone who's motivated to do that kind of development.
It's good and necessary that TDL has some form of built-in reporting, so this doesn't preclude that effort. But this will offer options to those who prefer to use other reporting products, especially commercial tools that they've purchased to get consistent reporting in their department or company.
2) For CSV/Excel exports, the library can be used in conjunction with other development tools like Linq-to-CSV or Excel automation libraries. With these tools and a class library, developers will have a much easier time creating custom export utilities.
3) Developers can use this to create outbound notifications where changes to TDL trigger emails, SMS, or other notifications.
4) Developers can use this to export data from other applications into TDL. Examples include creating new tasks for sales people to notify clients of some new event, or triggers to purchasing people to check vendor pricing when it's getting close to re-order time. Someone can even wire this to a Facebook app which gets new birthday events and updates TDL with a task to go buy a gift.
5) Mobile apps can be created which monitor the installation of specific versions of software. For company use, let's say you have a Task is to get all company mobile phones upgraded to v2.0 of a specific app. You know how many phones are in the hands of company employees. That count becomes you 100% mark to task completion. As each employee gets their phone updated and notifications are sent in, the %Complete flag is updated to reflect the new count. So if there are 50 employees and 20 of them have updated, %Complete = 40. And to complete the cycle, if a read trigger is on that, when that task is 100% complete perhaps an email can be sent to management that everyone has now updated.
6) This can help to bi-directionally integrate TDL with Bugzilla or other issue tracking systems.
7) Many FOSS projects (Drupal, Wordpress, MediaWiki...) send email when there is a new release out. You can have an app monitor specific accounts for mail from these projects, and when one is found that says "you need to upgrade your software", it will create a task in your website .tdl. Or you can be pro-active and have an app poll the various websites for new releases, whether checking their FTP sites or a portal/download page. So the app queries for an update and if found it creates a new task that you should check into it.
The possibilities are endless.
|
|
|
|
|
iamstarbuck wrote: The possibilities are endless. I don't doubt that, but _I_ only get stimulated when I have example code to actually work with!
|
|
|
|
|
OK, I need to spend less time writing About the library and spend more time actually coding the library and some sample apps.
|
|
|
|
|
Hi Dan
As I understand, View > Toggle Filter will toggle between the most recent filter and the default filter (i.e. All Tasks filter). To me, this feature is very convenient. Anyway, there's a minor issue as follows:
In the All Tasks filter, the default value of "Hide Completed Tasks" is false (unchecked). So whenever I use the Toggle Filter feature to switch back to the All Tasks filter, the completed tasks show up and I have to set the “Hide Completed Tasks” option back to true (checked).
There's an option under User Interface > Column Selection which is called “Always hide parent tasks in List View”. Is it possible to add a similar option called “Always hide completed tasks in All Tasks filter”?
Thank you for the most awesome todolist application known to me (at least)
Regards
Hoa
|
|
|
|
|
Bui The Hoa wrote: Is it possible to add a similar option called “Always hide completed tasks in All Tasks filter”? This would be too specific I think.
Better maybe would be to have a preference "Do not reset filter options droplist when toggling the active filter".
|
|
|
|
|
That would be awesome, thank you.
|
|
|
|
|
Hello Dan,
I was using ToDoList (Version 6.8.6) on my Windows 7 PC as usual a bit ago, and then out of the blue, I got this message from Windows:
"ToDoList has stopped working
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
I reopened TDL many times, tried opening backup files, and also restarted Windows, but kept getting the above message.
Any advice on how to trouble-shoot this problem will be greatly appreciated.
NT
|
|
|
|
|
The first thing I always ask is to see if you can spot a recurring editing pattern before the crash occurs, or does the crash occur without you 'doing' anything which would suggest a background task.
The easiest test is to close TDL, rename your ini file, then restart TDL and reload your tasklists.
If this 'fixes' it, then it suggests that some combination of preferences is triggering a bug in the code and we can try to narrow it down.
|
|
|
|
|
Hello Dan,
I didn't seem to have done anything unusual in TDL before the crash.
I renamed the ini file, and restarted TDL: everything was back to normal (except that the original settings were gone).
I then deleted the new ini file, changed the renamed original ini file's name back to "ToDoList," and restarted TDL: it didn't crash this time.
But when I tried to open any tasklist file directly--i.e., instead of starting ToDoList.exe first, I got the Windows' error message again.
Thanks for your help,
NT
|
|
|
|
|
Notetaker wrote: But when I tried to open any tasklist file directly--i.e., instead of starting ToDoList.exe first, I got the Windows' error message again. Great, this seems like the most useful line of enquiry.
What I need you do now is to send me the ini file and one of the tasklists (which I will delete on completion) that causes a crash, together with the precise steps that provoke the error message including whether it matters if TDL is already running when you load the tasklist via Explorer.
No need, I can reproduce this.
modified 19-Jan-14 3:43am.
|
|
|
|
|
I see this with multiple programs in Win 8.
I've no doubt the same would be true when running as a non-admin in Win 7.
I believe this stems from the new security models introduced with Win 7, and made more strict with Win 8.
It seems that these Win's do some sort of tricky / bizarre / stupid / <pick much="" stronger="" language=""> environment sandboxing, watch what the .exe's do / happens around them, then applies various bits around them.
This seems to be why the compatibility settings surround .exe's (go to the properties of an .exe, in there are various compatibility running modes that can be set) are present.
This has caused me no end of grief in Win 8, such that I can't get things working, and hope to never purchase an MS product again. Stuff was all just working, put it on Win 8, and forget it - it doesn't work. (ze/nmap is the latest victim of this that I've encountered.)
Anywho, I suspect the problem does not line within TDL itself, but within the environment Windows runs the .exe.
HTH, these are my best guesses / experiences, you certainly have my best wishes for sleuthing this out.
|
|
|
|
|
Was this intended for the "TDL won't auto update" thread, Bill?
|
|
|
|
|
No, this one. You're running along in 8.1 things are working ... and ... suddenly stop, for no apparent reason. Really frustrating.
But I now see how you might think that.
In that case, I'm going to guess that some sort of setting needs to be in the .exe header. (The specifics of which I have no clue.)
As I understand it, be it in the build of the .exe or windows itself since it dynamically creates a run time environment database, likely both, there are settings for permissions / capabilities required that get detected at load time. Thus, I suspect, windows will prompt 'you need to be an administrator', if the bit indicating such permissions are needed is present. I suspect the same is true at attempt to copy a file (like an .exe?) to certain places. Like C:\Program Files?
Until 8/8.1 one could run as administrator, or be an administrator and things would work, permissions were inherent to the account. UAC could actually be turned off pre-8. In 8+ you can turn off UAC, but it doesn't really turn off. PITA. The only way of which I can see around is to actually run as administrator. I mean literally Administrator. Which is 'bad' for all sorts of reasons, and certainly counter to all supposed best practices.
But is what Windows 8 forces people towards. (No wonder Chrome / Google / Android has come along.) Or, replace every piece of software you've come to rely on over the years. And face the re-learning curve and $, particularly on desktops, of the new touch interface. I have a desktop, and a real keyboard, for a REASON!
In this thread, what seems to happen is this dynamic run time environment database comes along and adjusts itself out of your ability to use the program at all. (This is anecdotal, I've yet to pin down / resolve exactly what's going on / how to fix at various times.) I wondered if that is what was biting the OP here. (Versus the update thread, where I expect an improved copy failure detection is needed by the installer - be it need to be an administrator or file permissions failure. Which, evidently since it's only now rearing its head, 'just worked' pre-8.) {And, I suspect, like myself, many people run as part of the administrator group for their own sanity.}
These compatibility modes, as far as I can see, is why the compatibility settings exist in an .exe's properties. Let alone, there is an XP compatibility setting, but is not exposed by that GUI. (But is in the task scheduler.) [It is the complexity of this run time environment ecosystem / compatibility settings, so many fingers in these puzzles, that is causing a great deal of frustration out there.]
iSpyConnect is a recent example for me - it collects cam feeds (e.g. nanny cams), and can also serve via an app built-in web server. Completely falls over for me as of 8.1 - it can open the port for listening, but AFAICT can't talk out the port it's just opened. Pre-8, just worked. For others on 8+, it works. And I've absolutely no idea in all this compatibility / run time environment ecosystem what to fix. (Assuming any gui even exposes the setting I need - if I knew what it was.)
Sorry to run off like this into the generic, but I do wonder if it is this sort of dynamic win thing, beyond TDL's control, that is biting the OP.
I can say, Dan, if you're not running 8.1, you might find it problematic to find and fix these sorts of win 8 things. Win 8 sandboxes in some way that pre-8 doesn't, and I suspect, if you can even duplicate a problem, you need to put it in a windbg level environment to detect what's stopping things in their tracks - to know what to look for to address. (Yet I wouldn't wish Win 8 on my worst enemy.)
|
|
|
|
|
Sorry Bill, I still don't understand what your comments have to do with 'TDL stopped working' which is a polite way of saying 'TDL has crashed'.
The crash was wholly related to a bug in my code and nothing to do with admin rights or anything else.
|
|
|
|
|
> Sorry Bill, I still don't understand what your comments have to do with 'TDL stopped working' which is a polite way of saying 'TDL has crashed'.
What I have been saying is that I am finding win 8 is imposing environmental restrictions that cause formerly working programs to stop working, over time.
> The crash was wholly related to a bug in my code and nothing to do with admin rights or anything else.
This time.
Perhaps not next. Remember, the comment was made before you had determined that.
|
|
|
|
|
Thx Bill, I now understand the point you were trying to make.
|
|
|
|
|
Hi Dan,
Updating ToDoList to Version 6.8.7 fixed the problem--thank you so much for the prompt action!
NT
|
|
|
|
|
The URL to this project changes with every new release.
Dan, what do you think about not putting the release ID and release status in the top subject line, so that URL stays more consistent?
We can get to the page using simply:
www.codeproject.com/Articles/5371/ToDoList
but I don't think a lot of people know that, so a copy/paste of the URL looks more like:
Articles/5371/ToDoList-6-8-5-Feature-Release-An-effective-and-fl
(That and other variants always work because CodeProject simply ignores most of it.)
Thanks.
|
|
|
|
|
I use the URL
http://www.codeproject.com/tools/todolist2.asp
for this page.
|
|
|
|
|
Hentoiy Razoir wrote: I use the URL http://www.codeproject.com/tools/todolist2.asp for this page. There ya go. Two people who are familiar with how CodeProject works and we use two different ways to access this page. With that URL I believe the URL changes to the current one when the user visits. Not so with http://www.codeproject.com/Articles/5371/ToDoList[^]
Note that if you get a permalink from forum threads that it uses the URL that you used to come to the site plus it adds the thread/response IDs. Those URLs are too long and too ugly right now. And from what I've seen the /tools/todolist2.asp link doesn't work with permalinks either (because the permalink uses the long/current version. But the one above does.
If Dan can just put the version data in a second header line rather than updating the primary header on every update, then we'll get a consistent URL that everyone can use.
|
|
|
|
|
I'll have a think about it.
It's the way it is intentionally because the version number alone tells people to update.
|
|
|
|
|