|
The .childnodes is part of the XML processing. Unfortunately there is no way to do this in AHK that I am aware of except if I write my own XML library. I am not willing to do this as (1) this would be an insane amount of effort and (2) Dan uses MSXML as well, and for data security I would rather use exactly the same library as Dan.
Alternatives
1) Compile the script to exe and run as exe (with AHK then your default installation)
2) Keep the AHK_L exe somewhere (just unzip from the install - do not install), and write a loader script (in vanilla AHK) that runs the script (one line of code - run %PathToAHK_L% %PathToScript%)
3) I can also see if I can find a place to upload binaries - which you can run directly - once in a more stable state this will probably be a good idea in any case.
|
|
|
|
|
capital H wrote: I am not willing to do this as (1) this would be an insane amount of effort and (2) Dan uses MSXML as well, and for data security I would rather use exactly the same library as Dan. That's understood and especially if it's such an amount of work.
capital H wrote: 1) Compile the script to exe and run as exe (with AHK then your default installation) Exactly. That "workaround" came to my mind, too. I run all my scripts as exe files whether I call a call a script once or if it runs all day long.
At present (in the testing phase) I will try this:
capital H wrote: 2) Keep the AHK_L exe somewhere (just unzip from the install - do not install), and write a loader script (in vanilla AHK) that runs the script (one line of code - run %PathToAHK_L% %PathToScript%) Thanks for your help.
Last but not least a little suggestion:
Would it be possible to offer different options regarding the creation of a new task like ToDoList offers that in the menu 'new task'? I suggest a dropdown field and the option "new task below selected task" could be the default. Just an idea...
|
|
|
|
|
TCP_JM wrote: I run all my scripts as exe files whether I call a call a script once or if it runs all day long.
Me too - trying too figure out which instance of autohotkey.exe relates to a rogue script in task manager is too difficult (and I have rogue scripts far too often!).
TCP_JM wrote:
Last but not least a little suggestion:
Would it be possible to offer different options regarding the creation of a new task like ToDoList offers that in the menu 'new task'? I suggest a dropdown field and the option "new task below selected task" could be the default. Just an idea...
Well, yes and no.
No because the new task creation is actually handled by ToDoList.exe, and not my script. This means that wherever TDL creates the task, will be where the task is.
Yes, because I can handle new task creation myself (and if you can remember this is the way I did it initially), but I am not keen to go back to this approach (mostly because of the lack of knowing what the default values for fields will be).
Yes (and this is the current plan) because I can intercept *any* of the TDL new task creations - and work from there. It is on my Todolist, but will be limited to the new task options with keyboard shortcuts (as I cannot intercept menu commands - though once this tool is more complete I may make a feature request to Dan - but I first need to figure out what the feature request will look like).
Yes (this is probably better, but I need to think about possible consequences) I can delay the task creation (via the postmessage command) until after you have pressed save. I can then have the default dropdown correspond to whatever shortcut key you used.
|
|
|
|
|
Three times YES and only once NO. Promising.
My next idea might be not the best one on earth but...
How about this:
At first your script creates a new task in ToDoList and after that your script starts to work on that task outside of ToDoList if I'm not mistaken.
Now. If your script would offer the droplist it would offer different options. The idea would be to code the script in a way that it first sends the postmessage code for that particular 'create task' option that the user has chosen in the dropdownlist.
E.G.
PostMessage, 0x111, 32799,,, AbstractSpoon (for 'new task below selected task) or
PostMessage, 0x111, 32807,,, AbstractSpoon (for new subtask at bottom of selected task) and so on.
ToDoList will create then the task according to the PostMessage (or SendMessage) Code and after that you script can start working on that task outside of ToDoList.
Droplist
Option 1 Option 2 Option 3 Option 4 ...
| | | |
Postmessage Postmessage Postmessage Postmessage ...
Code for Code for Code for Code for
Option 1 Option 2 Option 3 Option 4
| | | | |
---------------------------------------------------------
|
all the other commands in the script
because they are the same for every option
|
|
|
|
|
TCP_JM wrote: At first your script creates a new task in ToDoList and after that your script starts to work on that task outside of ToDoList if I'm not mistaken.
Correct
TCP_JM wrote: Now. If your script would offer the droplist it would offer different options. The idea would be to code the script in a way that it first sends the postmessage code for that particular 'create task' option that the user has chosen in the dropdownlist.
E.G.
PostMessage, 0x111, 32799,,, AbstractSpoon (for 'new task below selected task) or
PostMessage, 0x111, 32807,,, AbstractSpoon (for new subtask at bottom of selected task) and so on.
ToDoList will create then the task according to the PostMessage (or SendMessage) Code and after that you script can start working on that task outside of ToDoList.
I will consider it.
The problem is that currently I do not load the task (with say existing values for Risk, priority, colours, due date, start date, etc) - but I plan to someday. With this approach I cannot ascertain what the default values would have been (for the ones that are customisable/inheritable). If I can find a way around this - I will implement it - if I cannot - data accuracy trumps ease of use every time in my book (since you can move the task to where you want it).
|
|
|
|
|
capital H wrote: I will consider it. Thanks. Highly appreciated.
capital H wrote: ...data accuracy trumps ease of use every time in my book Absolutely!
|
|
|
|
|
Can you have a look at the newest version posted
It is not where I wanted it to be - but I think it is closer. Unfortunately I have a bunch of stuff for work that I have to do this weekend - so no progress will be made in the next week or so.
|
|
|
|
|
capital H wrote: Can you have a look at the newest version posted Yes, of course.
capital H wrote: so no progress will be made in the next week or so No problem. That gives me more time to test the new version of the script
We are not under pressure here, are we? Haste makes waste.
"Have a nice WE" - I have to work, too.
|
|
|
|
|
First of all:
Thank you very, very much for "creation date". That is such a big help !!!
1. It is a very (!) good solution to offer the script as a download. It makes it a lot easier to get the script.
2. Another very good idea is to offer it with a name that shows the date, like 'TDL New Task Creator upload 2011-12-09.ahk'. Makes it a lot easier to identify the version.
Beta - Test (v0.2 )
1.) The script works like a charm. I love 'File link'.
2.) "Made Dropdown arrow bigger". Sorry, but I like the smaller ones better. Reason: Everything looks very "filigree", the height of the WinTitle, the close button in the WinTitle, the little arrows in the time fileds etc. These big drowdown arrows are "breaking ranks" optically.
3.) "ComboBox width now pixel aligned". Good work, looks very professional.
"Little things":
a) The description text of the fields is not shown completely, e.g 'TDL Filename' is 'TDL Filena' , 'Creation Date' is 'Creation Da'.
b) I suggest to give 'TDL Filename' a whole line. I suggest the same for the field 'Title' with 'Task' in it.
If you agree to that I suggest that you expand the "create New Task' window (by or 50, 60%). That would make it easier to see the whole path to the *.tdl file. Another reason is that the 'create New Task' window can be embellished on a grand scale. This window is the new 'control center' for creating new tasks, isn't it?
c) It would be very useful if the word 'task' in the field 'Title' would be highlighted by default after calling the 'create New Task' window.
d) It's a logical thing to offer 'creation time', too but the user cannot see the time he has chosen in ToDoList because ToDoList doesn't offer the view. Question is: do we need it? I think we should keep it. You never what ToDoList offers in the future.
e) 'Category' and 'Status' (not present yet) could be put in the same line. Ditto for 'Allocated to' and 'Allocated by'.
f) After the script has made ToDoList create a new task ToDoList saves the list. And only after that the 'create New Task' window appears. This can slow down things if you have a large tasklist. I assume that this can't be totally changed, right? I assume the saving routine is necessary because the script needs "a stable" tasklist before working on that tasklist outside of ToDoList.
A solution could be to let ToDoList save the list in the backround and presenting the 'create New Task' window while ToDoList is saving. This way the saving of the list wouldn't be interrupting the workflow.
A little "inconsistency":
The script makes ToDoList create a new task. After ToDoList has done that the 'create New Task' window of your script appears.
Let's assume that the user clicks on 'cancel'. Result: the script doesn't work then on the tasklist outside of ToDoList.
But there is an inconsistency here: I'd expect the new task (created by ToDoList) to disappear after I click on cancel but the new task remains in the tasklist although the user has chosen to cancel the creation of a new task.
It's obvoius why we get this result; ToDoList creates a new task but the script doesn't take care of that task anymore when the user cancels the operation.
I would like to suggest that the script sends a PostmessageCode to ToDoList that makes ToDoList delete this new (useless) task it just has created if the user clicks on 'cancel' or on the 'close' button in the WinTitle.
An idea for a distant future of this script (I'd rather call it 'tool').
How about adding the option 'number of tasks'. That is to say that the script could ask the user how many tasks he would like to create in a row. E.G. if the user chooses '3' the script could present the 'create New Task' windows three times (one window after the other). The user can always choose between 'save' and 'cancel' to get to the next 'create New Task' window.
|
|
|
|
|
TCP_JM wrote: a) The description text of the fields is not shown completely, e.g 'TDL Filename' is 'TDL Filena' , 'Creation Date' is 'Creation Da'.
Sorry - I made the width narrower to test something and forgot to change it back - easy fix though.
TCP_JM wrote: b) I suggest to give 'TDL Filename' a whole line. I suggest the same for the field 'Title' with 'Task' in it.
If you agree to that I suggest that you expand the "create New Task' window (by or 50, 60%). That would make it easier to see the whole path to the *.tdl file. Another reason is that the 'create New Task' window can be embellished on a grand scale. This window is the new 'control center' for creating new tasks, isn't it?
Agree - the code is actually there to provide an option to give file link a whole line or not - just need to expand it
TCP_JM wrote: c) It would be very useful if the word 'task' in the field 'Title' would be highlighted by default after calling the 'create New Task' window.
I know why this is happening - and I have just thought of a fix - will add to my long list...
TCP_JM wrote: e) 'Category' and 'Status' (not present yet) could be put in the same line. Ditto for 'Allocated to' and 'Allocated by'.
I am not going to manually put stuff on the same line or not
You will see there is code to hide some fields (which means if it is hidden I cannot put it on the same line), and a setting for number of columns. I will at some time consider putting in custom order, and putting in blank placeholders.
TCP_JM wrote: f) After the script has made ToDoList create a new task ToDoList saves the list. And only after that the 'create New Task' window appears. This can slow down things if you have a large tasklist. I assume that this can't be totally changed, right? I assume the saving routine is necessary because the script needs "a stable" tasklist before working on that tasklist outside of ToDoList.
A solution could be to let ToDoList save the list in the backround and presenting the 'create New Task' window while ToDoList is saving. This way the saving of the list wouldn't be interrupting the workflow.
I will need to make a choice:
1) Have TDL create default/inheritable values and load from there (my code is geared towards this at the moment - although I am not loading it yet).
2) Ignore inheritable/default values - which means I can delay new task creation
TCP_JM wrote: A little "inconsistency":
The script makes ToDoList create a new task. After ToDoList has done that the 'create New Task' window of your script appears.
Let's assume that the user clicks on 'cancel'. Result: the script doesn't work then on the tasklist outside of ToDoList.
But there is an inconsistency here: I'd expect the new task (created by ToDoList) to disappear after I click on cancel but the new task remains in the tasklist although the user has chosen to cancel the creation of a new task.
It's obvoius why we get this result; ToDoList creates a new task but the script doesn't take care of that task anymore when the user cancels the operation.
I would like to suggest that the script sends a PostmessageCode to ToDoList that makes ToDoList delete this new (useless) task it just has created if the user clicks on 'cancel' or on the 'close' button in the WinTitle.
I agree
TCP_JM wrote:
An idea for a distant future of this script (I'd rather call it 'tool').
How about adding the option 'number of tasks'. That is to say that the script could ask the user how many tasks he would like to create in a row. E.G. if the user chooses '3' the script could present the 'create New Task' windows three times (one window after the other). The user can always choose between 'save' and 'cancel' to get to the next 'create New Task' window.
Interesting though - I had an idea where I parse the clipboard, and use each line as a new task title and let the user fill in the rest.
Will consider it - though only once the rest is stable, and I can think of a clear and concise way to present the choice to the user (this will be made easier with the principle decision above if I choose the second option of delaying task creation)
|
|
|
|
|
capital H wrote: I am not going to manually put stuff on the same line or not ... which means if it is hidden I cannot put it on the same line Understood.
capital H wrote: I will need to make a choice:
1) Have TDL create default/inheritable values and load from there (my code is geared towards this at the moment - although I am not loading it yet).
2) Ignore inheritable/default values - which means I can delay new task creation
Another thought regarding default values:
I understood that it's difficult (or not possible) to "read out" the default values set in the ToDoList preferences.
I'd like to suggest therefore that the default values in your script should be "a blank" for every field then (exception 'Title' with 'task' in it and the 'TDL Filename', of course).
Another theoretical option could be that your script and ToDList are storing different "preferences". This way your script wouldn't have to read out the default settings of ToDoList (it would have it's own settings then).
BTW: I' using an AHK script that is writing it's own ini-file. Maybe that's an option for your script, too.
Thanks for all your work!
|
|
|
|
|
|
I should have been more transparent - but with the new commandline options in 6.4, I suspended the development until it was more final.
Using the commandline options is easier, and better (since the whole delay saving/loading the tasklist issue is avoided).
I have not played much with the 6.4b1/6.4b2 (and I cannot remember why I did not want to to it with the alpha version), but I suppose I can start work on the beta version (i.e. I can probably assume that the switches/format will not change - and if there is a bug then Dan will probably fix it in 6.4 final/6.4.1/6.5)
|
|
|
|
|
Thanks for your reply.
capital H wrote: Using the commandline options is easier, and better (since the whole delay saving/loading the tasklist issue is avoided). I agree, but I liked your approach, too.
Thank your for working on the script in advance.
Cheers,
Jochen
|
|
|
|
|
Good day, .dan.g., do we have any hope to have the features discussed some time ago implemented (http://www.codeproject.com/Messages/2261873/Feature-Request-Quick-Task-Entry-Date-Parsing.aspx, http://www.codeproject.com/Messages/3299392/inline-parsing-for-fast-entering-of-tasks.aspx)? Or, probably, there some AHK scripts that can be shared by you, guys?
|
|
|
|
|
I don't know how MLO does it but it strikes me as being quite tricky to get get reliably right.
First there's the issue of multi-language support: It's hardly appropriate to make users write in English if they're working with a full translation of ToDoList in their native language.
Secondly, even if we were to force them to use English (and with proper support for translation in 6.3 English speakers may become a minority), non-English speakers often construct their sentences according to their own language's syntactic rules.
Thirdly, how do we give appropriate feedback to users when they inevitably make a mistake.
|
|
|
|
|
As for task parsing, you are absolutely right, it's not an easy issue taking into consideration support for non-english users (btw in MLO there are only two options for parsing, in English and Russian, operands for both are fixed, i.e. cannot be changed and reassigned by users). Anyway, my suggestion is to initially make it in, say, English with the possibility to reassign the triggers in your native language (Ex. -d or *d stands for date, a user can reassign this combination, it can be like reassignment of shortcuts) In such a case you do not oblige people to use only English, what is to be translated later is only the description of parsing commands.
Regarding construction of non-English sentences. Well, generally speaking notions in all languages are all the same (start, due, Saturday/sat, remind, etc). You as a maker of this program can limit the quantity of commands, because the main target of this topic is to facilitate work not vice versa.
The third point, this one I didn't get well enough, what kind of mistakes do you mean, if change of parsing rules is restricted to reassignment of "shortcuts", nothing is going to happen.
Btw, what is your position towards quick task entry, is it feasible?
P.S. I do use mostly MLO at the moment but there only a few things that restrain me from switching completely to TDL and I will definitely do this because of their feedback.
P.P.S. Did you ever consider introduction of logical operands?)
|
|
|
|
|
Perhaps what I'll do is to extend the existing commandline options to allow the specification of more task attributes and then we cn see if we need to also provide a new interface.
|
|
|
|
|
I consider implementation of quick task entry in Things to be a good one (culturedcode.com/things/wiki/index.php/Quick_Entry_and_Autofill) especially with options to paste into a new task/existing task. As for commandline options, I didn't quite get how to do this, because there's kind of lack of documentation on this, or at least I wasn't able to find it..
|
|
|
|
|
Thx, that looks like a much better model.
I particularly like the idea of grabbing the clipboard text and allow the user to drag'n'drop from the clipboard text into various fields.
Imaging a dialog displaying edit fields or droplists for a task's attributes together with a multiline edit field below displaying the clipboard text.
The user can drag-highlight bits of the clipboard text and then drag the selected text into any of the attribute fields, including dates. This would be especially handy for creating tasks from emails.
Your thoughts?
modified 6-Dec-11 0:23am.
|
|
|
|
|
For me it looks a bit compicated, the simplier - the better. First of all, we need to define the purpose of use of QTE, in my opinion, that is to 1) make part of information (clipboard text, email, etc) a task, an action, 2) grab your inspiration and immediately inscribe it (eg you are struck by an idea, don't have time to open a program, find an appropriate field to fill in, etc, you just hit a shortcut and add your vision - hey, that's the action, and this one is a sub-action, and another one, and here I would put deadline, say, 25/12/2011 (that is why I consider text parsing useful, applicable for QTE only). After you are done, just send your geniuous ideas to limbo (in terms of GTD, Inbox folder) and get back to them as soon as you are ready to revise them and make your ideas really actionable).
There can be even more tricks to play with QTE, I like the Gyroq, addon for Mind Manager (http://www.gyronix.com/gallery/browse.php?home=Gyronix-Video-Library.txt&help=this), the idea and implementation rock, unfortunately I was not able to find a similar standalone application for accumulation and further processing of your prompt ideas/thoughts/tasks, it can be very useful, for example, when you are brainstorming a project.
As for GUI, my vision of necessary elements is as follows: 1) option to choose a tasklist to go if you have more than one, 2) option to add subtasks 3) display of link (if you drag highlighted text from a browser window, you'll have an URL in comments, if an email from an email client - link to the body in it), 4) option to parse text, eg, pr10 would mean priority 10, etc, in such a case GUI will not duplicate the main window and will not be overloaded by lots of input fields and buttons.
What do you think about such implementation?
|
|
|
|
|
mugrrrr wrote: What do you think about such implementation? I will take your comments into consideration and follow my intution.
ps. If you want to send me some screenshots of other products, feel free.
|
|
|
|
|
.dan.g. wrote: If you want to send me some screenshots of other products, feel free.
Here we go.
Firstly, for me the neatest HUD design I've ever seen is of Things, and now I'll explain why.
Screenshots: http://www.laketa.com/wp-content/uploads/2011/03/Things-quick-entry.png, http://jetplanejournal.com/jetplanejournal/wp-content/uploads/2009/04/picture-20.png.
Fields in QTE of TDL:
1. Task name.
Input of multiple tasks should be allowed, as well as subtasks, so, this field will be extendable depending on how many tasks/subtasks you add. Subtasks can be added like in, eg, MLO (via blank space) or via any other dividers.
2. Categories.
There you can choose a proper category.
3. Comments.
Simple text comments, no drums and whistles, because you need to grab your task in a fast/quick/rapid way, not create a masterpiece.
4. URL/link.
It's not actually a field, a line, that displays a source of a task (email, webpage).
5. Due date.
My second link is to show a calendar, very convinient to choose a certain date.
6. Task goes to a folder that you can choose (eg, if no folder is chosen, a folder "Inbox" is created at top level and the task goes there).
Now some comments.
1. If there's text parsing, fields like "Due date" or "Priority" (I didn't mention that one because I think it to be redundant) are not obligatory, you can make a report ^due 20/12/2011 ^pr 6.
2. If you work with more than one tasklist at a time, you need to choose a proper one, there's should be a separate field for it, probably, after a "Folder" field.
|
|
|
|
|
|
No, thank you
|
|
|
|
|