|
_BS_ wrote: It would be useful to be able to call a user defined tool upon save I'll add this to 6.9.
|
|
|
|
|
Open TDL, no tasklist specified.
Tools / Preferences / Enable '.tdl' as a file extension for tasklists - unchecked
File / Save Tasklist As - Save as type: == Unicode Tasklist (*.xml)
Tools / Preferences / Enable '.tdl' as a file extension for tasklists - checked
File / Save Tasklist As - Save as type: == Unicode Tasklist (*.tdl, *.xml)
* the addition of *.tdl being significant / the difference.
From (Wiki) prefs
Enable '.tdl. as a file extension for tasklists
Allows you to open tasklists by double clicking them in Explorer.
Note: This will write a key to the registry.
Note: if you intend to copy your tasklist to your website then be aware that some XML parsers will not recognize your tasklist unless it has a .xml extension.
Problem:
(1) In essence, checking that preference makes THIS todolist.exe the one associated with .tdl files.
- but I could run many todolist.exe's in many different directories, or of many different versions.
= I will have only 1 'production' version of todolist.exe though, and nothing else should touch that association.
~ all bets are off for even more complex situations / users - they're on their own. If they got this far, they know how to roll with it.
(2) There is no direct association between what explorer uses to open .tdl files and what files are .tdl files. i.e. .tdl is always a .tdl file regardless of the explorer association. In TDL's mind, at least. A conflicting app also using the .tdl extension is that app's problem. (Presumably the user will avoid opening the other app's .tdl files in this app, and vice versa. If they do, their problem - they likely won't more than a few times before always being mindful of the issue.)
(3) Which todolist.exe currently has the association? It's not apparent to the user.
Suggestion: Beside that spot in prefs, put a button: Associate this tdl in explorer. (That way when it's the wrong one the user can go to the right one and repress it, never doing so in any other todolist.exe / being able to recover if they do so accidentally. Not to say the same effect isn't accomplished by un/checking this box, merely that a separate button is more user friendly / intuitive / apparent.)
Solution:
All file interaction dialogs, save as, load, whatever, should ALWAYS include the .tdl file type. This preference setting should have no impact upon file display.
- arguably, if all file dialogs include *.tdl, this preference should not be a checkbox, but a button, as above. Perhaps coloured appropriately if this .exe instance is the current handler. Green = Yes, Red = Not. With same said textually afterwards - for some reason I personally always get the colours backwards.
[By button I mean same size element / icon as current, but instead of being checkable, being pressable. This preference is more an action than a setting?]
Alternate:
Create another pref to always list .tdl files or not. (But I don't think that is necessary, always show .tdl files - if you're using the .xml extension instead, it will simply never show any .tdl files - there won't be any. If they do exist, such a user probably wants to know about it - it's likely an oops.)
Confluster:
Someone in a multi-TDL environment, e.g. Work and personal will -
(a) Want only one of them to be the default .tdl handler.
(b) Not see their .tdl files in file / open in the other. == Frustrated user / extra support calls.
(c) Be trying to keep .ini settings separate, and may want no (TDL set) association in explorer (so that designated list open pathways must be used, to keep required .ini/.tdl file association pairs intact). But still, in all cases, if they go file/open, they expect to see .tdl files listed.
[It would be, in almost all cases, insane not to assume a .tdl file is a TDL file - the reverse is not true, not all .xml files are TDL files. Insane in the sense of pointlessly creating a perpetual point of user confusion - a .tdl file is a TDL file, but is this .xml file a TDL file or something else?]
All file dialogs should include *.tdl.
CDN$0.02
-----
By extension, the above may also apply to "Enable 'tdl://' as a url protocol", but I haven't investigated.
- it would not be unreasonable to always treat tdl:// as a protocol. It should always be, in TDL's mind, at least - representation in other programs is the other program's problem. As a protocol if only for formatting purposes - e.g. underlined and/or italicized.
- the same argument applies as above - just because tdl: is a protocol (and displayed as such), doesn't mean -this- instance of TDL is the desired handler.
So, tdl: should always be displayed as a link, just like *.tdl should always be displayed as a TDL file. This preference setting shouldn't impact that. (Assuming the purpose of the setting is to bless this instance of TDL to be the handler. Thus it too could be a button, as above.)
- whether or not links are displayed as such is a different issue. Perhaps even another preference setting. (I hate it when LibreOffice displays every e-mail address underlined, when I'm maintaining a list of e-mail addresses, never intending to click on one and begin composing a message.) But such a setting is generic to all links, not TDL links in particular. Display, or not, shouldn't be a side effect of this particular preference.
Thanks for listening.
|
|
|
|
|
The tricky thing here is that TDL was written as a portable app, and having '.tdl' as a recognised Windows file type and/or 'tdl://' as a recognised Windows protocol requires writing to the registry which is non-portable.
Also, some browsers will not load an XML file unless it has the '.xml' extension.
I'm happy to revisit these decisions but it's not cut and dried.
|
|
|
|
|
> and/or 'tdl://' as a recognised Windows protocol requires writing to the registry which is non-portable.
Good point, but I don't think it applies to what I'm saying. It does point out that I didn't well cull out that use case.
(1) What I am saying for the preferences is that whether .tdl files are listed, or tdl: urls underlined, is a separate beastie from the preferences. Within .tdl itself, .tdl files should always be listed, regardless of preference setting, and tdl: links underlined. And the .ini can reflect that. To your point, whether the registry does is a wrinkle to be ironed out, but TDL itself and its .ini can be clear on that.
- but I take your point that file registrations / url associations touch the registry, and that may not be what is desired at that point.
- neither of which impact .ini, nor display of anything within TDL itself. Largely, these associations / registrations affect non-TDL use of such files / protocols.
(2) A file protocol in text is a file protocol in text, and should always be underlined. (The pref should actually be whether to underline file protocols at all. Perhaps with an accompanying button, as described, to register this TDL as the handler. But these are separate / distinct / disconnected concepts, being bundled within the same preference setting.)
(3) I would have thought all file dialog windows would be called via something like OpenFile( window handle, initial file display filter). All I am suggesting is that filter should always be '*.xlm;*.tdl' - which I would have thought was under TDL control / specification. (That such a filter reasonably covers all cases is explained in prior.)
So: these 2 particular preference settings are bundling 2 distinct things within the same boat, and the 2 distinct things aren't always both on or both off - one on / one off is reasonable. [e.g. Don't register file type, but do list *.tdl files in file dialogs.] File dialogs should always include a *.tdl filter present (if the current filter is not *.*) - which I would have thought is under TDL coding control.
|
|
|
|
|
Hello Dan,
If you could put up with one more "interesting idea" from me, I've got a pet wish for the comment field: the addition of an editing command button for a dynamic-length horizontal-line separator (like what Evernote has for its editing window). Such a separator would be very useful for quickly marking off a large amount of text in the comment field into manageable sections.
Currently one can draw dividing lines by repeatedly hitting the hyphen or underscore key, but, besides being a bit hassleful to produce, these keyed-in lines also cannot change their lengths according to the changing widths of the comment field, so that they would sometimes double over, and sometimes become too short for the resized comment field.
Many thanks again for your consideration,
NT
|
|
|
|
|
In the rich-text comments there is a option to insert a horizontal line but this is just a very long long fixed line (that uses 'table' technology), though it should display correctly.
|
|
|
|
|
Hi Dan,
Could you tell me how to access this option? There doesn't seem to be a command button for it in the rich-text comments.
Thanks,
NT
|
|
|
|
|
hi dan
TDL is software with many useful options. i tested many sticky notes beside of TDL to see some task on desktop.
can we have communication between some tasks with your simple STICKY-NOTE on desktop (to enable this we can have check box or define date/time to show on desktop)
BR.nasehi
|
|
|
|
|
(Yes, I know - I'm not Dan ..)
Maybe I don't understand you correctly, but under "Preferences - General - last entry on the right side" you can enable the cooperation with software "Stickies":
http://zhornsoftware.co.uk/stickies/index.html[^]
It this what you are looking for?
Pierre
|
|
|
|
|
The way I read it either they're looking for stickies to talk back (e.g. just coming up with this, if they dismiss the stickie, isn't that tantamount to completing the task and TDL could mark the task completed.) [Yes, I know, it's one way TDL to stickies, but I can appreciate the ask.]
Or they're looking for the stickie to be date/time stamped.
(My read, anyways.)
|
|
|
|
|
thanks Pierre & _BS_
i do your suggestion. i am beginner for that("Stickies"). it is good for the first step. but how we can see tree view with check box on "Stickies". if it is possible, so let me know. i think "Stickies" has one-way communication(is that true?).
|
|
|
|
|
(Somewhere while searching I came across a relative paths [in .ini?] thread, including a query from Dan if something wasn't relative in there.)
.ini/SpellChecker/EnginePath looks to be an absolute path.
|
|
|
|
|
|
All lines beginning with SoundFile= refer to absolute pathes in my ini file.
Merry Christmas by the way.
|
|
|
|
|
I am a firm believer in not using custom keystrokes, macros, and so on.
I may sit down in front of a dozen different users computers on any given day, to help them out. I would go bonkers if everyone set different keystrokes. Thus when I install or template I leave things at their defaults. e.g. Ctrl-Esc (Start)
However, I have seen in practice that the TDL keystrokes are not intuitive to some. [No matter what is chosen, that will be true for some - any developer is beat before they start.] For some reason (not that I understand it,) some people 'get' Insert to add a task while not getting Ctrl-N to do the same.
So, while I don't begrudge people setting keystrokes that make sense to them, I do begrudge it when their doing so kills the native keystroke.
I would like to suggest an enhancement to custom keystrokes, to add another column (Alternate keystroke).
Moreover, I would suggest that the alternate column default to what mlo uses - it seeming more intuitive for some users. (Let alone would make converts productive faster.)
Free mlo at Download MyLifeOrganized - Light Edition (freeware) - go all the way to the bottom (Ctrl-End), then up one.
At a quick glance, that seems to be (ignore any standard / default / duplicated keystrokes - and ignore keystrokes that don't apply to tdl):
Open ^o, save ^s, print ^p, search ^f, insert date/time f4, insert time ^t, insert date !^t, previous day ^-, next day ^=, previous week ^@-, next week ^@=, properties @f1, toggle task list/task notes @1, zoom in ^r, zoom out ^@r, collaps/expand subtasks ^`, collapse entire outline f6, expand entire outline f7, toggle contexts filter / to-do @a, view / set bookmark 0-9 !^0-9, view / goto bookmark ^0-9, next bookmark ^., previous bookmark ^, , bookmarks ^@, duplicate task ^d, move to ^m, select contexts @l, toggle weekly goal @w, manage contexts f8, Synchronize f9
New task, Ins, New subtask Alt+Ins,
Where: ^ = Ctrl, ! = Shift, @ = Alt, f = function key, symbols (+,-,etc) = keypad
[I may not agree with those particular choices, but they are the choices mlo chose. Thankfully, even if these were defaults, the current functionality would let me change them.]
Personal Overrides of above: a la windows explorer, +, -, expand/collapse (likely already defaults),
Just as long as I can set my own personal defaults (as current), the ability to set alternates may help some - particularly if defaulted where it makes sense, for converts.
CDN$0.02
P.S. Oh ... and a reset to defaults button would be useful.
|
|
|
|
|
I'll give it some thought.
|
|
|
|
|
\tdl>.\todolist.exe mylistlowerdir.tdl - works
\tdl>.\todolist.exe ..\mylistupperdir.tdl - works
cd ..
\>tdl\todolist.exe mylistupperdir.tdl - brings up a blank list.
tdl does not appear to be looking in the current directory, or following a relative path to the specified file.
It also seems confused when the .exe directory is not the current one.
What are the rules for tdl, where the current directory could be anywhere / full path to .exe used, for finding the .tdl file specified on its command line? (Assumption: same rules apply for finding correspondingly specified .ini file?)
|
|
|
|
|
Because TDL was designed to be a portable app, it has always taken the exe folder to be the root from which relative paths are searched.
|
|
|
|
|
So, specifying a path relative to the exe is expected to work?
Could the current location rules used be listed please?
And could an enhancement request be logged, please:
- (in addition to current functionality, so current use does not break)
- locate the list file relative to cwd, as is standard, as well.
(- if a 'dir {file}' can find it, TDL should as well.)
- if the list file cannot be found, so indicate, and ask if a new file is to be created.
|
|
|
|
|
_BS_ wrote: Could the current location rules used be listed please? If a path is relative, the app path is prepended, else the full path is taken as is.
For relative paths using one or more '..\', these are resolved using Windows API calls.
_BS_ wrote: locate the list file relative to cwd, as is standard, as well. I will add this after the existing checks.
|
|
|
|
|
Thanks. The extra ..\ would never have occurred to me.
> one or more '..\', these are resolved using Windows API calls.
Wha???
(What stupidity is Windows doing on us now?)
Mind you ... could be the same thing batch files use - %0\.. == current directory.
|
|
|
|
|
It would be helpful if Help/About could add some information.
- current working directory
- path to .exe
- path to .ini
- path to current list (for simplicity, assume current task tab).
I expect to have multiple lists with a specific .ini associated with each. (Essentially, different users will maintain different lists, and I don't want one users preferences to munge anothers.)
Being able to make sure such cross-pollination isn't going on by being able to see the above would be helpful.
Especially when an empty list comes up for mysterious reasons and need to be sleuthed out.
|
|
|
|
|
_BS_ wrote: current working directory
- path to .exe
- path to .ini
- path to current list (for simplicity, assume current task tab). Good idea, I'll add it to 6.9.
|
|
|
|
|
Hi Dan,
could you please also consider to show the actual commandline incl. all parameters assigned to the .exe when called via a link, batch or script on the cmd?
This would help to make out problems with commandline-parameters.
These can be quiet beasty regarding blanks and quotes etc.
Regards
Chris
|
|
|
|
|
TELL ME ABOUT IT!
Just went through this myself. (Not TDL's fault, Windows!)
Turns out ',' is also a delimiter. Sometimes.
'this, is an arg' turned in to %1 = this %2 = is an arg
ARGHH!!
Let alone 'start /w tdl "%1"' keeps the quotes ...
(STUPID WINDOWS!)
Couple things that helped:
set thisListName=%1
set thisListName=%thisListName:"=%
for %%a in (Lists\%1.tdl) do set thisListPath=%%~pa
See set /? for explanation, around '%PATH:str1=str2%'
|
|
|
|
|