|
So - here is a simple draft / question list which I noted while I was looking around in the existing files. There are some questions, some hints which I suppose to be OK and some notes which could be interesting for translators.
How_to_translate.txt
What is the structure of the file?<br />
Which structure is recreated by "add-to-dictionary" feature? What is why written to which section?<br />
<br />
Do not edit the language file while TDL is active - your changes will be overwriten when TDL is closed.<br />
Use a copy of CSV to edit and copy it to your language file while TDL is closed.<br />
Translate the strings in section "need_translation" and then move these line to section "translated".<br />
It is allowed to sort the lines it their referring sections.<br />
Duplicated lines can be removed if thes are really(!) duplicated?<br />
<br />
What to do if I find untranslated strings in the translated section?<br />
<br />
Is it allowed to move untranslated strings to the translated-section (to sort it and to create same translations for same strings)<br />
<br />
The third columns with entries like "menu..., label..." can / must not be modified?<br />
<br />
The content of section "need_translation" can be deleted if you are not sure if it is correct. The software will refresh it with new entries.<br />
<br />
The CSV file has to be saved in XY-format. (UTF-8? UTF-16? ANSI?)<br />
<br />
How to handle Mnemonics?<br />
<br />
What to do with strings like these:<br />
"!" "" "text"<br />
"%" "" "text"<br />
<br />
What to do if translated strings are still displayed in English?<br />
<br />
Which special characters like \r \n \t are used?<br />
<br />
What to do with repeating entries, like<br />
"0 (Lowest)" "" "combobox.1183"<br />
"0 (Lowest)" "" "combobox.1191"<br />
"0 (Lowest)" "" "combobox.1032"<br />
<br />
What to do with truncated strings?<br />
<br />
How to find and what to do with strings, already translated but no more needed by the software?<br />
<br />
<br />
What to do with obviously wrong lines like<br />
"&1 (Ohne Titel)" "" ""<br />
"&1 rmf19" "" ""<br />
"&1 C:\DOCUME~1\...\Temp\rmf17.tmp" ""<br />
<br />
Pierre
|
|
|
|
|
|
Hi Dan,
there are bigger bugs in the recurrence/ocurrence system in 6.4.7.
The steps:
* Create a new task on top of your list, please.
* Set 'start date' to May 22, 2012 and 'due date' to June 01, 2012.
* Open 'Recurrence' and set 'More than Once' to 'daily' and set 'Calculate next ocurrence' to 'from start date' and set 'When I complete this task' to 'reuse the existing task'.
* Press 'ok'.
* Click in the checkbox, please to complete the task.
Bug 1: Result 'start date' and 'due date' are changing both! Why?
Expected Result: 'start date' should be May 23, 2012 and 'due date' should remain June 01, 2012.
Bug 2: The result I get is: 'start date' = May 13, 2012 and 'due date' = May 23, 2012
If I click again in the checkbox I get: 'start date' = May 4, 2012 and 'due date' = May 14, 2012 and so on.
You can get strange and wrong (!) results, too when you set the recurrence to weekly etc.
Thanks in advance for taking care of this.
Cheers,
Jochen
P.S. Same problem in 6.5
|
|
|
|
|
TCP_JM wrote: Expected Result: 'start date' should be May 23, 2012 and 'due date' should remain June 01, 2012. I disagree. IMO the duration of a recurring task must be maintained when the next recurrence is calculated. Hence moving both the start and due date. Otherwise what would happen when the start date reached June 02 and the due date was still June 01?
Nevertheless I agree that the calculation does appear to be wrong inasmuch as the due date ought to have been moved to June 02, 03, etc.
TCP_JM wrote: You can get strange and wrong (!) results, too when you set the recurrence to weekly etc. It may be the same bug for both.
ps. I can confirm that the calculations do look royally messed up.
|
|
|
|
|
.dan.g. wrote: I disagree. IMO the duration of a recurring task must be maintained when the next recurrence is calculated. Hence moving both the start and due date. Otherwise what would happen when the start date reached June 02 and the due date was still June 01? I disagree that the duration of a recurring task must be maintained in this very situation.
IMO it shouldn't happen that 'start date' reaches June 02 if 'due date' is June 01. If 'start date' reaches June 01 it shouldn't be possible to use the checkbox to set 'start date' to June 02.
I would like to suggest that ToDoList informs the user then about this conflict and asks what the user wants to do.
'Due date' should not be shoved automatically to a later date since 'due date' is - especially in business affairs - a deadline that has to be met !!!
The whole idea of maintaining that the "duration" of task must be maintained" seems a little strange to me.
Let's have a look at a task that has no recurrence and let's say the 'start date' is May 23 and the 'due date' is June 01. The user wanted to start working on that task very early (he knows he just needs one day to complete the task) but then he can not start on May 23 for some reason and changes 'start date' to May 27.
What will happen. 'Start Date' changes but 'due date' remains the same. AS EXPECTED!
Why should this be different if a recurrence is involved ???
modified 22-May-12 0:52am.
|
|
|
|
|
TCP_JM wrote: 'Due date' should not be shoved automatically to a later date since 'due date' is - especially in business affairs - a deadline that has to be met !!! Can you give me an example of a recurring task whose start date changes but not it's due date?
ps. Lots of exclamation marks won't add weight to your argument
|
|
|
|
|
I modified my message here[^] a little. Could you please have a look. Thanks!
.dan.g. wrote: Can you give me an example of a recurring task whose start date changes but not it's due date? Very easy.
Let's assume you have a fixed 'due date'. It's engraved in stone. Your client wants the results on that very day.
You are setting an early 'start date' and you start on that very day to work on it but can't complete it. You are filtering your list by start date. What are you going to do now if you want your task to show up on the next day again in your list? You set the 'start date' to the next day. Ticking a checkbox is much easier than changing the 'start date' every day (by using the editing control 'start date').
The reason for this procedure is that there is no such thing as an editing control like 'working on this task' that could be used then as a date between the 'start date' and the 'due date' so that one doesn't forget to work on a task.
P.S. The exclamation marks didn't add weight to my argument?
|
|
|
|
|
This does not sound like a common use of recurring tasks. Indeed, I had never heard of such a usage until today. For the majority of users I am convinced that they expect an equivalent copy of a task shifted forward in time by the amount they have specified.
If we look at Outlook, recurring tasks are even more simple than this.
Q: Is this why you asked for the 'Start date' functionality?
Because if so, I would probably not have agreed, since it makes recurring tasks much more confusing, which is probably why I got it wrong trying to implement it. Which is my bad for not asking enough questions at the beginning.
|
|
|
|
|
.dan.g. wrote: Q: Is this why you asked for the 'Start date' functionality? Because if so, I would probably not have agreed, since it makes recurring tasks much more confusing, which is probably why I got it wrong trying to implement it. Which is my bad for not asking enough questions at the beginning. No, it's not your bad and no, that was not the reason why I asked for the 'start date'.
The reason to ask was that I put the emphasis on 'start date'. ToDoList was focused on 'due date' in many regards.
I thought (and still think) that 'start date' is - for the daily work - the more important date since it shows when to start working on a task to meet the deadline 'due date'. That's why I asked for the filter 'tasks started by'. The request 'calculating next ocurrence from start date' came later.
It's the combination of the filter and the recurring option that gave me the idea of using 'start date' the way I described it and you are probably right that this does not sound like a common use of recurring tasks.
So it's my bad that I tried to misuse the recurrence option!
The problem (for me) remains.
At present it seems that the easiest solution would be not to use the recurrence option then and just change the 'start date' in the editing control. This way the 'due date' doesn't get changed.
The other option, that is to say to create an editing control 'working on' (= 'work date'), is probably a lot of work for you especially because it will involve new filtering options that can be combined with 'start date' etc. and a new column (work date, work time). This editing control might be an option for the future since 'work date' would be a good hint in the calendar view, too.
|
|
|
|
|
My bad. I made a fundamental mistake when I added the 'Calculate from start date' functionality.
However, this might be a good time to clarify how the 'Calculate next occurrence' ought to work in all aspects.
My understanding is this:
1. Calculate from Due date means: Take the task's due date, add to it the number of days, weeks, etc specified by the user, save it back to the task's due date and then recalculate the start date so that the task length remains as before.
2. Calculate from Completion date means: Take the task's completion date, add to it the number of days, weeks, etc specified by the user, save it back to the task's due date and then recalculate the start date so that the task length remains as before.
3. Calculate from Start date means: Take the task's start date, add to it the number of days, weeks, etc specified by the user, save it back to the task's start date and then recalculate the due date so that the task length remains as before.
Where 'Task Length' = ('Due Date' - 'Start date').
|
|
|
|
|
I agree with your understanding, except for the part "so that the task length remains as before."
Especially regarding the 'due date'.
The farer the 'due date' lies ahead in the future the more unpredictable the result gets. And this makes the user forget about the real 'due date' then.
If a user postpones to start working on a task does that really change the 'due date'.
I'm under the impression that we are thinking of two different situations here:
You: Recurrence creates a completely new task with the same content. In this regard it makes sense to make sure that the task length remains the same.
I: Recurrence based on 'start date' ('due date' is different) just shows when I have to start or want to start working on a task or just when I want to work or have to work on a task. 'Start Date' is used an editing control 'working on this task', too. In this case it doesn't make sense that the task length remains the same.
|
|
|
|
|
Wouldn't the easy solution here be for you to write a AHK script that grabs the task's existing due date, then calls the default completion code and then restores the due date?
|
|
|
|
|
It's a bit tricky to work with AHK and the 'editing controls'.
|
|
|
|
|
I use this feature exclusively for recurring items that are the same each time. For example monthly meetings, or monthly reports. They also typically have the same start and due date. The functionality largely works for me, but then I often adjust the dates of the newly created tasks.
As I see it, there are 3 scenarios:
- do once (no recurrence)
- do on a defined date / date interval (e.g. every 4 weeks on a Monday, every 2 months on the 2nd)
- do on a relative date (e.g. every 2nd Tues of the month) - not available
The second option is the one you are discussing, and to get the anchor point for the date increment/calculation, one of start, due, or completed dates is needed. Your logic is what I would have expected, and agree the task duration should remain the same.
The only (minor) issue with this is if, say a meeting gets postponed. I need to change both the start and due dates, as otherwise an artificial duration may be created for the next time. But there is probably no simple automated way around this. I hope one day to create an AHK script that can increment both start and due dates together easily.
The third option doesn't exist (yet?), but would be nice, as most of my meetings and reports are set up on this basis. For now, I do the following:
I have a report the needs to be presented on the 2nd Monday of every month. I set the recurrence for, say, the 3rd of the month, and put "2nd Monday of the month" in the comments. I will then manually adjust the start and due dates when the task is created on completion of the previous task.
zajchap
|
|
|
|
|
zajchapp wrote: - do on a relative date (e.g. every 2nd Tues of the month) - not available ... The third option doesn't exist (yet?), but would be nice I second this.
This has been requested regarding the reminders before, too. Outlook options may serve as a reference. An option that allows a reminder or an occurrence like 'every second sunday in May' would be very helpful.
|
|
|
|
|
zajchapp wrote: I hope one day to create an AHK script that can increment both start and due dates together easily.
Assuming that you always want to increment 'start date' and 'due date' at the same time and that you never change the settings in the 'offset task dates' window (except for the number of days) you can use this little AHK workaround:
F1 calls the 'function'. The focus is then in the editing control 'by' because (I'm assuming again) that the number of days changes.
#SingleInstance force
#NoEnv
F1:: ; <-- change this hotkey if you want
SetTitleMatchMode, 2
#IfWinActive, AbstractSpoon
PostMessage, 0x111, 33054,,, AbstractSpoon
SendInput, {tab 6}
#IfWinActive
|
|
|
|
|
Thanks. Something to get me started.
I currently use the 'offset task dates' dialog, and typically bump both start and due dates forward by a number of days, weeks, etc. Lots of clicking involved.
My workaround - getting things done on time - only works intermittently.
zajchap
|
|
|
|
|
zajchapp wrote: Lots of clicking involved. Can you briefly list your procedure so we can look at ways it can be improved.
|
|
|
|
|
First of all I like to thank you, Dan, for offering the 'menu Item IDs' and the command line options.
ToDoList is already a great program but in combination with them it's even better.
Both (the 'menu Item IDs' and the command line options) are offering to address commands, menu items etc. directly which makes my life so much easier.
The "problem" (if it can be called that) are the dialog boxes/windows and the commands/options they offer.
Especially the 'print preview' but also the 'offset task dates' dialogue.
What could be (or is) the "problem" here?
Both dialogues are offering a lof of options which makes them so valuable for the user.
Most users (I'm sure) are having 'standard procedures' when working (with ToDoList) and the options in the dialogues are offering to cope with that (very flexible) but since there are a lot of different situations the user has different procedures and he always has to open the dialog and enable/disable options, changing things. Lots of clicking involved.
It would be great if the users could save some settings like it can be done with 'find tasks' (save search). That would help, especially regarding the 'print preview' dialogue.
|
|
|
|
|
I am not so sure this is worth stressing about, however, since you asked...
The issue is that I review my tasks in detail monthly. I am therefore going through up to 100 tasks (worst case), moving start and due dates. Sometimes I can do several tasks at once, but often not. So this process will be repeated many times.
So for every task, I need to:
- either - Click on start date, click on next month (usually once), select the date. Then do the same for due date.
- or - click open the 'Offset dates' (3 clicks normally, but I now have a key shortcut), then set the info in the dialog and click OK. It is very useful that the dialog remembers it settings, but the amount offset will change.
I probably use the first option the most, as going through the menus was more difficult (more points on the screen to hit). However, bringing the dialog up by a key shortcut should reduce this from now on, and gets around the issue of how deep the command is in the menu structure. I am still swapping between keyboard and mouse though.
Note: I should probably just train myself to navigate with the arrow buttons using my left hand, and adjusting dates with the mouse in my right.
My ideal would be an ability to offset dates with key presses. For instance, with a key combination (e.g. ctrl 1), increment start and due dates by 1 week. Or another key combo to increment the dates by 1 month (e.g. crtl shift 1). I could then navigate with the arrow keys, and adjust dates much more quickly.
Note: this could be implemented in 2 ways - e.g. to add 2 weeks, either press ctrl 1 twice, or by pressing ctrl 2.
I was intending to see if I could get AHK to do this, but I wonder whether this will be possible.
As I say, probably don't need to stress. The job is not a quick one whichever way you go, and with a bit of training I could probably speed thing up for myself.
zajchap
|
|
|
|
|
PostMessage, 0x111, 33054,,, AbstractSpoon opens the 'offset task dates' dialog.
The little script can only save you a couple of mouse clicks.
zajchapp wrote: My workaround - getting things done on time. That is - of course - the best "workaround" and I agree: "only works intermittently".
|
|
|
|
|
Thanks. It gives me something to play with, and familiarize myself with AHK and its capabilities. Nothing like examples.
I have set up a keyboard short-cut in TDL to bring up this dialog already.
See my post above for further discussion on my suggestions if interested.
zajchap
|
|
|
|
|
Read your post[^] above.
"I am not so sure this is worth stressing about"
I think ist is if you have to go through up to 100 tasks (worst case), moving start and due dates.
AHK is exactly the right program to cope with repeating tasks like pressing multiple keys etc.
I was intending to see if I could get AHK to do this, but I wonder whether this will be possible.
Yes and No. I'm not an AHK - Guru but I'm quite sure that some things regarding offset dates can be done and others can't.
The situation you have to cope with is always that you have to increase 'start date' and 'due date' at the same time, if I'm not mistaken.
I doubt it that it is possible to adress the commands in the offset dates dialogue directly, although it would be possible to play with the command line options as a workaround. But that's not necessary, because the 'offset dates' dialogue remembers it's settings.
I suppose you need three AHK sripts. One for day, one for week and one for month. You can easily use the hotkey you mentioned for this (ctrl 1, ctrl 2 and ctrl 3).
You could even create more scripts that cover different situations that you need very often: two weeks, 1 month etc.
All theses scripts would always rely (at present) on the fact that 'start date' and 'due date' can stay enabled.
The only big problem (that can't be solved at present IMO) is the situation if a user wants to change this all the time because sometimes he wants to only change the 'start date' and then only the 'due date' and then both.
I haven't the foggiest how to read out whether a command like 'start date' is enabled in the 'offset dates' dialogue or not with AHK. I wish I knew.
As long as 'start date' and 'due date' can stay enabled it's relativly easy to fulfill your needs.
If it is necessay to change only the 'due date' or only the 'start date' we have to go another way (read out the task ID, choose the date, and put it in the editing control by using a command line option. Something like this.)
Now: Something for you to play with.
The script covers it (put it in a textfile 'offset.ahk', save it and double click on it. The hotkeys only work if ToDoList is the active window.)
#SingleInstance force
#NoEnv
; CTRL+1 offsets the date by days
^1::
SetTitleMatchMode, 2
#IfWinActive, AbstractSpoon
PostMessage, 0x111, 33054,,, AbstractSpoon
SendInput, {tab 7}d
SendInput, {Shiftdown}{tab}{Shiftup}
return
#IfWinActive
; CTRL+2 offsets the date by weeks
^2::
SetTitleMatchMode, 2
#IfWinActive, AbstractSpoon
PostMessage, 0x111, 33054,,, AbstractSpoon
SendInput, {tab 7}w
SendInput, {Shiftdown}{tab}{Shiftup}
return
#IfWinActive
; CTRL+3 offsets the date by months
^3::
SetTitleMatchMode, 2
#IfWinActive, AbstractSpoon
PostMessage, 0x111, 33054,,, AbstractSpoon
SendInput, {tab 7}m
SendInput, {Shiftdown}{tab}{Shiftup}
return
#IfWinActive
Hope it helps. If you have questions feel free to ask, if you think the script should be improved, tell me, please.
Jochen
|
|
|
|
|
TCP_JM wrote: Now: Something for you to play with.
Many thanks for this. It is the fastest option yet, and I will move to using this code.
It also gives me a good understanding of how to access menu items in TDL, so that is great as well. I have been intending to go back though this forum to find TDL specific AHK scripts to learn off (and probably still will), but this gives me a good kick start. Hope to have a play this weekend.
The only thing faster would be for Dan to make some additional commands available, such as 'increment due date', 'increment start date', 'increment start and due dates'... But that would get complex & messy, as you would probably need to also specify day, week, & month. You would quickly end up with at least 9 commands... (incrementing 1 unit each). Probably not worth the hassle.
Again, many thanks.
zajchap
|
|
|
|
|
zajchapp wrote: ...many thanks You are very welcome.
zajchapp wrote: I have been intending to go back though this forum to find TDL specific AHK scripts I already did this when I started working with ToDoList. There is not much to find. Sorry.
This website[^] might be interesting for you. There are few scripts. I've put them there (they were written by Capital_H and by me [with help from Capital_H; everyone needs sometimes a little help, especially when they are starting to work with something like AHK, right? ).
I need to change a few things in the scripts after the realease of 6.5 since some of the 'Menu Item IDs' in ToDolist have changed etc.
BTW: In AHK they are called 'PostMessageCodes'.
zajchapp wrote: The only thing faster would be for Dan to make some additional commands available, such as 'increment due date', 'increment start date', 'increment start and due dates'... But that would get complex & messy, as you would probably need to also specify day, week, & month. You would quickly end up with at least 9 commands... (incrementing 1 unit each). I don't think that adding some additional commands would make it faster.
It would end up exactly where you said: lots of commands. It's probably not even possible to cover all possible combinations day and/or month and/or year; one day two days, three days or weeks or years...etc.
Have fun playing with the script. Hope it helps and it supports your work. And if you have a question...
|
|
|
|
|