Suggestion: Support $arguments in UDT Icon field (and Path?)
42 views
Skip to first unread message
Tony G
Nov 17, 2016, 12:00:19 PM11/17/16
to ToDoList (AbstractSpoon) Support
While doing testing related to another discussion, I noticed that the UDT $(todolist) placeholder is supported in the Path field. This is great so that we can say "use This TDL exe" rather than having to hardcode it.
I also noticed (duh?) that we can just say "todolist.exe" and it defaults to the current execution folder, which is ideal.
For some UDTs I also set the Icon to the current TDL exe. The $(todolist) placeholder there isn't resolved like the Path. But again, "todolist.exe" resolves to the current folder, which gets the job done.
Then I thought there could be applications for having a more variable UDT Icon. For example, with an icon file for each category or tag, we can display an appropriate icon that operates on a given task type. Or with an icon file corresponding to a tasklist $(filename) we can show something like an email icon, only offering an email UDT for projects where it's valid.
With that, I'm hoping that the Icon field will support all $arguments exactly the way the Arguments field does. I would only request this if the change is as easy as running the Icon field through the same handler as the Arguments field. If it's more complicated then I honestly don't have an immediate use for this.
And while one could then suggest that the Path support $arguments too, I can only think of limited use cases for that. What if we create a custom field which indicates a reporting type, like Email or Letter. Then put the custom field into the UDT execution path like Client_$(seltcustom, cust_rtype).exe. So the program executed will be Client_Email.exe or Client_Letter.exe. The Arguments field could also be used to pass in that parameter so that a single program (or a .bat) file can then parse the arguments and call whatever the ultimate utility is. So this is just another way of doing that kind of operation. I don't have a personal application for this, but if the same function can easily be used to reconcile all three of the fields in the UDT dialog, then there is some elegance in consistency, and versatility if anyone does want it.
Thanks for your consideration.
T
I also noticed (duh?) that we can just say "todolist.exe" and it defaults to the current execution folder, which is ideal.
For some UDTs I also set the Icon to the current TDL exe. The $(todolist) placeholder there isn't resolved like the Path. But again, "todolist.exe" resolves to the current folder, which gets the job done.
Then I thought there could be applications for having a more variable UDT Icon. For example, with an icon file for each category or tag, we can display an appropriate icon that operates on a given task type. Or with an icon file corresponding to a tasklist $(filename) we can show something like an email icon, only offering an email UDT for projects where it's valid.
With that, I'm hoping that the Icon field will support all $arguments exactly the way the Arguments field does. I would only request this if the change is as easy as running the Icon field through the same handler as the Arguments field. If it's more complicated then I honestly don't have an immediate use for this.
And while one could then suggest that the Path support $arguments too, I can only think of limited use cases for that. What if we create a custom field which indicates a reporting type, like Email or Letter. Then put the custom field into the UDT execution path like Client_$(seltcustom, cust_rtype).exe. So the program executed will be Client_Email.exe or Client_Letter.exe. The Arguments field could also be used to pass in that parameter so that a single program (or a .bat) file can then parse the arguments and call whatever the ultimate utility is. So this is just another way of doing that kind of operation. I don't have a personal application for this, but if the same function can easily be used to reconcile all three of the fields in the UDT dialog, then there is some elegance in consistency, and versatility if anyone does want it.
Thanks for your consideration.
T
Reply all
Reply to author
Forward
0 new messages