|
|
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%'
|
|
|
|
|
+1
And, never mind only list path of current tab.
May as well show them all.
Probably also useful to list what the temp dir is. i.e. where -g output will land.
At some point, this is all more than is reasonable for Help/About
Perhaps another entry is called for. Help/Debug (?)
That way additional diagnostic information could be added over time, without continually torturing help/about.
|
|
|
|
|
|
Thank you for the post.
I am struggling with this very thing myself right now.
Despite specifying a .ini to use - no joy.
- I later saw that -i takes a path (ambiguous as to directory or full filename), but still no joy yet.
Thank you for the note that .exe/.ini's are in pairs.
Does this mean that for each list I must keep a separate directory structure with it's own .exe (and the .ini MUST reside beside it?) in order to get different preference settings?
I have yet to come across an explanation for -i use, other than the parameter exists. Anyone have any links?
Could the .ini file used please be whatever I tell it to use in the command line? e.g. ./programs/tdl/todolist.exe ./Lists/myfirstlist.tdl -i ./Lists/myfirstlist.ini
|
|
|
|
|
Hi,
Dan explained to me that there is not such thing as dedicated pairs of .exe/.ini files.
I had the feeling that it used to be possible to have such thing, but Dan stated that isn't anymore.
None the less it works for me to use two links on my windows-desktop pointing to a localhdd bound todolist.exe (say in c:\tdl\) and two different tasklist (.tdl. One is a "team tdl" on a networkshare the other one is my personal one on local hdd. This work quiet well for me. If i click on one after another they load in one instance of the todolist application in different tabs.
Btw. i can set different settings regarding collumns to be shown under /View/Select Columns/.
Samples for these two links:
C:\Todolist\ToDoList.exe "-i C:\Todolist\ToDoList.ini" "C:\Todolist\localTDLs\2dos_personal_20131215.tdl"
C:\Todolist\ToDoList.exe "-i C:\Todolist\localTDLs\ToDoList2.ini" "V:\TDLs_Team\TDL_global_2013.tdl"
What i would expect from the "-i" commandlineparameter is that dedicated pair .exe/.ini thing.
But the ToDoList2.ini is not considered at all at the moment.
There is more in the links given in my last posting.
Regards
Chris
modified 19-Dec-13 10:04am.
|
|
|
|
|
> Dan explained to me that there is not such thing as dedicated pairs of .exe/.ini files.
I don't believe that to be strictly true. As -i appears to be broken at the moment, I expect things are reverting to default, where it looks for a todolist.ini, by name, in the same directory as the .exe it's coming from.
-i may not have been broken, and may get fixed, but I expect this default behaviour will always be true / a fallback.
> I had the feeling that it used to be possible to have such thing, but Dan stated that isn't anymore.
If you are referring to what I think passed by my screen not long ago, that's not what he said.
He said a single .exe can not (nor would it ever have been possible) to make use of 2 .ini files simultaneously.
I do expect, and happy to be corrected, that two .exe's in different directories can run simultaneously each making use of their own .ini files.
And I suspect (if -i was working), you could get the same result in the same directory by copying the .exe to another name (or .lnk?). e.g.
copy todolist.exe todolistpersonal.exe
ren todolist.exe todolistwork.exe
todolistpersonal mypersonalfile -i mypersonalfile
todolistwork myworkfile -i myworkfile
But even 'better' in a sense, for the person who has a local and a network copy. With one shortcut C:\Program Files\TDL\todolist.exe mylocallist.tdl, and the other N:\Network Files\TDL\todolist.ex n:\network files\mynetlist.tdl.
> None the less it works for me to use two links on my windows-desktop pointing to a localhdd bound todolist.exe (say in c:\tdl\) and two different tasklist (.tdl. One is a "team tdl" on a networkshare the other one is my personal one on local hdd. This work quiet well for me. If i click on one after another they load in one instance of the todolist application in different tabs
But will be sharing the .ini.
As I understand it you could get the same effect via:
todolist.exe -f "localfile.tdl|netfile.tdl"
> C:\Todolist\ToDoList.exe "-i C:\Todolist\ToDoList.ini" "C:\Todolist\localTDLs\2dos_personal_20131215.tdl"
As Dan said, neither of us understand how this can possibly work.
C:\Todolist\ToDoList.exe -i "C:\Todolist\ToDoList.ini" "C:\Todolist\localTDLs\2dos_personal_20131215.tdl"
we'll believe (quote after -i, not before), and even then, given todolist /?, I would expect it to fall over, unless specified as:
C:\Todolist\ToDoList.exe "C:\Todolist\localTDLs\2dos_personal_20131215.tdl" -i "C:\Todolist\ToDoList.ini"
If it's working for you, great. Don't be surprised if it stops, though - that it is I would assume to be a fluke. (Something's not right, and when it gets caught and 'fixed' according to spec, you're going to break.)
> What i would expect from the "-i" commandlineparameter is that dedicated pair .exe/.ini thing.
I don't expect there is a dedicated pair. Merely a default location where the .exe looks for the .ini.
> But the ToDoList2.ini is not considered at all at the moment.
Which is consistent with what's been said above and elsewhere.
Windows will code share instances of an .exe. And perhaps some level of data (initial stack?). Thus the observations that only a single .ini is possible.
Let alone, Dan's nicely coded single instance, so one of its first moves will be to see if it's already running. (Although Dan may wish to confirm that permitted multiple instances are reading their own .ini's - help/about enhancements requested elsewhere will help ascertain that.)
If your links called distinct instances of the .exe, I expect you will get the behaviour you are looking for. (To be confirmed.)
Just what windows considers distinct, at this point, is what I wonder.
Same .exe complete path won't be distinct. Same .exe in different paths might be - I'm assuming there's no unique .exe identifier in an .exe's header. If there is, then renamed .exe's won't work either. [Work around, use different versions of todolist.exe.]
-----
> There is more in the links given in my last posting
I've been finding a number of people's such links to not be working for me. Some do, some don't. I assume threads have scrolled off or been purged in some cases. e.g. I'll get a search hit but when opening I get the entire page and positioned at the top. (Confirmation of this effect would be useful.) [It'd be nice if such search results didn't come up, either, for that matter. No point tantalizing me with a search result, then not letting me read it.] {If that's not anyone else's experience, please let me know - must be something goofy with my browser, then.}
----
FWIW, in my questions on this subject ... I don't expect two instances of tdl on any machine at a single point in time. I'm creating a multiple list solution using dropbox, and I need each list to have its own .ini - so one maintainer's preferences don't schmuck anothers. Two instances from the same file space may run at the same time, but I don't expect them to be on the same machine at the same time. (Each in a different list, and different associated .ini file.)
For the moment, and since -i appears broken, and I can't assume it won't break somewhere down the road again, I'm trying each list with it's own .exe directory, expecting the coinciding .ini to be distinctly used.
modified 19-Dec-13 13:30pm.
|
|
|
|
|
_BS_ wrote: I've been finding a number of people's such links to not be working for me.
You mentioned that about a reply I sent you recently. I looked at these links prior to posting, and they were working...
[Edit: The links Chris posted all work for me as well]
And FWIW. For quite some time now I have run 2 instances of TDL - one set up for task management, the other for structured note-taking (task names and comments only). To avoid all the above or regularly changing views, I have just got 2 separate 'installations'. Effectively pairing the .exe & .ini
But I realise this is not what you are trying to achieve.
zajchap
|
|
|
|
|
Thanks. On both accounts.
I'll have to dig in to the links next time I notice the problem.
And thanks for the confirmation on the 2 instances.
What you are doing is what I have moved to - nice to have confirmation that it will work. (And if it doesn't, problem is likely PEBKAC.)
Should also work, then, for the other poster - just copy the exe to a 2nd name, and call that in the 2nd link.
Appreciate the post.
|
|
|
|
|
A couple of things I forgot to mention.
I am running two versions of TDL - one current, one slightly older. Not sure if this has any bearing, but just in case it does. I have the two instances running side by side happily for weeks between restarts.
Also, I do not mix my files from one installation to the other (as they have different purposes). I have not tried opening a file in one configuration, then opening it in another (i.e. different ini files).
[Edit: Just to be clear (I may have misunderstood). It is not just the .exe I am replicating. I have two completely separate installations, with all the folders, files etc...]
|
|
|
|
|
Hi Bill
In looking at the code for processing the commandline I noticed that it was not very clear to me what was going on.
So I refactored it and, in doing so, discovered a bug in the handling of relative .tdl files. I will submit a fix over the w/e.
|
|
|
|
|
Thanks.
Any chance you sleuthed out what happened with -i processing in the exercise?
While you're in that area ... you might touch the /? text ... it wasn't entirely clear to me whether the -i arg was a filename or a dirpath. e.g. It wasn't clear to me whether a .ini could be any filename other than todolist.ini.
|
|
|
|
|
|
Can anyone confirm the problem from this thread still exists in 6.8.x or not?
I was considering changing to multiple calls to the same .exe file using different ini's via -i, but reviewing this thread is giving me pause.
If I understand the thread correctly, running:
C:\pathtomytdlinstall\todolist.exe mylist1.tdl -i mylist1.ini
C:\pathtomytdlinstall\todolist.exe mylist2.tdl -i mylist2.ini
Will not do the expected. (The thread discusses the unexpected need to run .exe/.ini in pairs despite it not supposed to be needed.) In this case, the expected might be different column visibilities set in preferences.
Dan notes in the thread he is unsure of the current command line processing, and expected to review / refactor / revitalize in 6.9.
Just in case the problem no longer (or never did) exist, or I go botch my production area ... can anyone confirm starting 2 instances of tdl as above (multiple instances permitted) works as expected / different column visibilities?
Thanks.
[PS This is on XP, but could be Win 7. I do understand there are issues with non-admin's trying to store .ini's in C:\Program Files or other admin program locations, so will watch for that.]
|
|
|
|
|