The same result comes from plain text or rich text.
Pasting that into Word or Outlook, the entire text is converted to a link.
For some other applications the text is simple pasted as text.
Is that happening in TDL or is something else intercepting the text and converting it to a link?
Presuming that you have installed the Windows desktop client (that maps to a folder in Explorer) you should be able to just copy your existing install and tasklists to that folder, and run it from there.
The only important thing to remember is to use 'Simple Source Control' so that you don't accidentally overwrite any tasklists that may be open concurrently in different locations.
The default save format for TDL is UTF-16 with two leading BOM characters 0xFFFE to indicate little-endian format. This is the same format for both the .tdl files and for generated .csv exports. We can Save As a .tdl to switch to ANSI/UTF-8 with no BOM.
I'm wondering if there are any other formats now or in the future that need to be supported for read/write by the ToDoList Library. The reason is that I need to detect the encoding of files on a read, and save with the same format. I also need to get the code to save new files with the default format, but allow for legal alternatives.
If it is not currently possible is it an upcoming feature?
Is it possible to view the hours remaining in the burndown rather than the number of remaining tasks?
Presumably this would just accumulate 'Time Remaining' on each incomplete task?
Note that the calculation for 'Time Remaining' would be as-defined in the 'Attribute Calculations' part of the preferences.
I'd like to have the burn rate and projected completion date
This would require assistance on your part for how these should be calculated.
Not intended so much as a request for changes, just food for thought and info for other users...
I'm starting to use links to TDL tasks in code (TDL Library) and I noticed clicking the links didn't launch the TDL app.
OK, I'm on Windows 8.1 and we need to open TDL as Administrator in order for the registry to get updated for this. Done.
( Preferences dialog -> General -> tick 'Enable 'tdl://' as a url protocol' )
But when TDL opens it doesn't open the same ini that I normally use. My shortcuts use this:
C:\Installs\ToDoList_6.9\ToDoList.exe -g -i C:\Users\me\Documents\foo\Tasks\ToDoListLive.ini
I completely understand what's happening.
The registry key is this:
and the command in there is this:
C:\Installs\ToDoList_6.9\ToDoList.exe -l "%1"
(That's an L switch to handle a Link to a specific task. TDL will select that task ID after launching.)
So I modified the registry key to combine the commands above:
C:\Installs\ToDoList_6.9\ToDoList.exe -g -i C:\Users\me\Documents\foo\Tasks\ToDoListLive.ini -l "%1"
Whoopie, now it launches to the right ini, list, task.
But there's one small issue. When TDL opens like this a new instance opens. The option is unchecked (and disabled) for Preferences -> General -> Allow multiple instances of ToDoList. I'd prefer to use the existing instance, with whatever files are already open there, and if the requested file isn't open then add it. Otherwise just set focus to the correct tab before selecting the task. Right now a list will open in a new instance even if it's already open in an instance currently being displayed - there's potential to have changes in both instances.
Dan, in a recent discussion you mentioned that you can use the current path/ini for some other option we were discussing. (Passing this data to a UDT?) As long as you're getting that data (maybe the entire command line) then you should be able to use that to set the tdl:// custom protocol.
One issue that I see here: What happens if someone registers tdl:// and then reinstalls TDL to a new folder. I do this with each new release for testing. When TDL starts, the current path may not be the same path in the registry. I'm wondering if there is value to a checking mechanism to warn the user that using tdl:// will not open the current environment.
Yeah, if I do specify the ini then it opens a new instance, even if an instance with that ini is already open. In this case it'll have the same .tdl open in both instances. To summarize - if an instance is open with a desired ini, I want to use it, and use the .tdl there if it's already opened.
I propose the following behaviour:
- Where the ini is not specified, and there is currently one open instance (regardless of the ini), use that to open a link. The "default" ini in this case is the one that's already open, not the one in the app folder. If the file is already open, use it, otherwise open it.
- If an ini is specified and there is a single instance already open with that same ini, then that's the instance that should open the file.
- If an instance is not open for a specified ini then a new one is opened.
- Where there are multiple instances already open for a given ini, and the .tdl is already opened in one of them, use that instance.
- Where there are multiple instances already open for a given ini, and the .tdl is not opened, open a new instance with the specified ini or the default if no ini is specified. In this case, the app shouldn't randomly decide which instance gets the file.
I wanted to create a quick reference from code back to the .tdl that applies to that code.
So in code I have this link: "tdl://34" (Obtainable from Edit>Copy As>Task Link
I don't want to hard-code references to the location of specific .tdl files, and especially not to specific folders on my PC. So that short link is fine.
To use: I have software (PhraseExpress) that allows me to assign hotkeys to functions, sort of like AHK, and in this case I can select the link and hot-key to launch the related application.
I already have TDL open and my ToDoListLib.tdl file open. On opening that short link, focus actually does go directly to TDL and the active tasklist, and the selection moves over to the right task. WOW, that's impressive.
Now, if I get a full link, it includes the path like this:
That goes to the current open instance, shifts focus to the right .tdl, and then down to the right task. WOW again, impressive.
However, as I said, I don't want to include the full path. If the user already has the file open, I want to use that file. Assume this change to the link:
If TDL is open and the .tdl file is visible, that link still jumps to the correct task.
But if TDL is open with another .tdl file selected, it will attempt to open the file from the current folder for the application that's open (the Visual Studio project file). I would hope (going back to my last post here) that it will detect the file is already open and use that as the default.
Is it possible that someone has 'their' foo.tdl file open and a reference to 'my' foo.tdl is not the same? Sure, but the chance of that is slim. Now, there might be an issue: That my .tdl was saved using my ini preferences, and someone else opening it with their ini preferences might alter the behaviour. Sure, but that's a problem we face now with this anyway. I think it's safe to assume that we can use the same rules suggested in my last post to open this file.
Finally, what if the user does not have ToDoListLib.tdl file open? In this case, it's valid to attempt to open it from the current path, as TDL already attempts to do.
As usual, that's not a series of requests but my own "food for thought" exploration into this great functionality.
As I'm doing testing on the TDL Library I was wondering why a Flag type is denoted with a "+" rather than as a Boolean with a "1" or "0".
I also noted these fields do not appear in the Edit area. The only way to change a Flag field is by clicking the grid. I don't see anything wrong with that - it works fine. I was just wondering if that was by-design or an oversight.
This is another one of those "we'll be able to do this with the library" things. Workin on it. Of course that's not changing the view within the app, only an external rendering, but it's something to look forward to.
To get a transform of a list by IDs, you suggested we go to the List View. But since there is no hierarchy in the temp data that's output, we can't grab an ancestor in XSL for a task's parent ID. So is it in the queue to add a PARENTID attribute to tasks in the temp file?
I just noticed that the time spent for one of my tasks is +0.3 hours from the total time recorded in the log. I used Excel sorting, grouping, and sub-totals on the log, and manually compared the total of each task to the value in Time Spent. Luckily this is a new client with new projects, tracked with TDL starting with (I believe) B7 or B8.
To account for the discrepancy, I did enter 3 test adjustments in B7 for 0.1, and another test adjustment for -0.3 to offset them. These are in the log properly, it's the .tdl that has the wrong value.
It would be very tough to check other lists that have such a discrepancy. With the TDL Library I can write a utility that does this but the code is in a weird state now pending integration of the 6.9 schema.
Is anyone else seeing something like this?
- Run a transform that includes your time spent. This data comes from the .tdl.
- Run an analysis By Task for all time. This data comes from your logged time .csv.
The numbers should match if:
- you have all logged time in the same file,
- you do not uncheck "also add time to task's time spent" when adjusting the log,
- you are not manually modifying the time spent field in tasks.
I can manually just reset the time for this one task but I'm in a panic about the scope of this.
It's possible that I did not check "also add time to task's time spent" when posting the -0.3 value to the log. I don't think there's anyway to know.
Since logged times ought to get rounded up or rounded down to approximately the same extent, I would not expect this difference to be due to the precision of the logging.
However, there is the possibility that adding time to the log file fails, and therefore time is added to the 'Time Spent' field but not to the log.
FWIW, you are the first person to seriously use this functionality (at least on the basis of your extensive questions ) so it's always possible that bugs are lurking. I'll look in my end of things over the weekend.
FWIW, you are the first person to seriously use this functionality (at least on the basis of your extensive questions ) so it's always possible that bugs are lurking.
Love to help, hate to be bleeding edge with live data.
Seriously, I know you put a lot of this together based on my feedback. I'm aggressively making it a part of our billing/reporting processes. I just sent out first reports to a client today with a transform and analyses (post-processed with a bit of Excel, which I'd like to automate on my side). Of course I benefit from our collaboration, but I'm quite happy to help flog the new functionality into shape ASAP for all who use TDL.
And I'm both extremely grateful for your efforts there, as well as always leery of asking for too much. I'm sure you'll draw the lines wherever you feel comfortable.
I can see that vision as well, and I am an entrepreneur. I agree that the free software (including the library[^]) plus for-fee value-add addons would be an excellent vehicle for broadening the scope of the utility/platform without compromising the ethos of freeware. As long as people here are still getting what they want for free, I don't think anyone will have a problem with a separate initiative to broaden the scope with for-fee extensions.
This is deep stuff. While I don't mind airing thoughts in public, I really dislike the discussion mechanism on this page. Perhaps we can pursue the discussion in email or Skype and then publish thoughts elsewhere.
First, I think, we get the bridge component working for a simple case like an exporter, then we build on that to create a must-have business-oriented component that we can deliver from within TDL (say by adding 'Store' top-level menu to the app).
Do you need anything more from me to get the bridge component up and running, because I'm happy to help write that bit?
As long as we don't get mired in details I think it's cool for peeps to see what's in the works here, so no email for now.
By Bridge, I think you mean the C++/CLI middleware to facilitate .NET plugins to be invoked from the app? Yeah, I just haven't had time for getting deeper into that, so it would be helpful if you could do that. I suspect you might discover new hooks that could be added for events from TDL to whatever listener is linked. If you're as distant from the CLI as I am from C++ then we can meet in the middle somewhere. I do have experience there (enough to serve as a reviewer for a book on the topic) but I haven't gone there in years.
And yes, I'd like to follow-that with a couple plugins, with source, to serve as POC/examples.
As to the Store concept, I'm thinking it might be enough for peeps to be able to link whatever DLL is advertised to work with TDL. In-app linkage seems like a 7.1+ convenience. I'd be concerned about malicious DLLs, and this project getting blamed for letting bad things happen. Accessibility can't be confused with certification or advocacy. Now, if you're just talking about a link to a list of available apps, yeah, there are plenty of examples of that in the industry. That's a deeper topic for later.
suspect you might discover new hooks that could be added for events from TDL to whatever listener is linked.
To start with this will just be for Importers and Exporters so there will be no event notifications.
I'd be concerned about malicious DLLs
I'm not proposing a 'Store' that anyone can post to, it would just reference a location that I own and where I have already validated the plugins that exist there. ie. all plugins would have to go thru me.
Time is logged in 100ths of an hour. For Analysis reports the data is rounded up to the nearest 10th. This can result in a 0.01 difference depending on the data and report. Can we get an option for Analysis which will export totals as 100ths with no rounding? That way any rounding done in post-processing "should" yield the same results.
I don't see this as critical but our invoicing is going to be off about a buck from reporting, and while some people won't question 80 hours of time, they will ask about that buck.