|
We've discussed this before to an extent but now that we have the tracker I'd like to flesh out the idea into a formal proposal.
We can create a UDT with the -cmd switch to execute a menu option. But if we open a form, that's where it stops. I want to fill in the form and continue on to execution.
So for example, If I want to do a Transform, I can go to Preferences, Keyboard Shortcuts, check "Show menu item IDs", scroll down to Tools, and see that Transform Tasklist is code 33024. With a click on the toolbar I can now open that form just like Alt-T from the keyboard. But I can't use the UDT to fill in any of the fields. I need to check a couple controls, click OK, select a file, click Save, click Yes to over-write an existing file. I want to create a UDT that does all of that for me.
Might we be able to work toward an extension on -cmd which allows for selection of controls, entry of data into fields, and activation of events like Click?
Ultimately it would be cool if TDL were more of an engine encapsulated within a UI, where the UI and a UDT both have full access to the engine via an API. Then TDL would essentially be a client of itself, facilitating a headless engine which could be used elsewhere. Right now it's all integrated, not a MVC model, so I know that would be a huge effort. Hey, a guy can dream, no?  [EDITED] Bad idea.
Is this where I should be using AutoHotKey[^] and scripting everything? If so, I might create a small library of scripts and facilitate their use through my Nebula UDT. I would welcome collaboration with anyone who is already doing something like this with AHK.
Thanks for your time.
modified 28-Aug-15 11:28am.
|
|
|
|
|
iamstarbuck wrote: Might we be able to work toward an extension on -cmd which allows for ... entry of data into fields ...
This is feasible but could create enormous future compatibility issues because it makes it harder for me to make subsequent changes out of fear of breaking existing scripts.
iamstarbuck wrote: if TDL were more of an engine encapsulated within a UI, where the UI and a UDT both have full access to the engine via an API
This is nowhere in my current plans, sorry.
iamstarbuck wrote: Is this where I should be using AutoHotKey[^] and scripting everything?
Possibly, but I'm no AHK aficionado.
---
It seems that the current problem/issue with transforming outside of TDL is that you lose all the selection/filtering/attribute options of the Transform dialog which are used to create the intermediate file passed to the transform code.
So what if I added a new commandline switch for the purpose of producing the intermediate file on demand?
This would allow you to write a script/batch file that first produces this file and then post-processes it with whatever additional options you want, including passing your own 'ini' file with whatever extra info is required to meet your needs...
If it's trivial, I'll add it to the next update and then we can see what opportunities that opens up.
|
|
|
|
|
.dan.g. wrote: It seems that the current problem/issue with transforming outside of TDL is that you lose all the selection/filtering/attribute options of the Transform dialog which are used to create the intermediate file passed to the transform code.
My other thread/suggestion is about transforms, I just used that here as an example, sort of dove-tailing the concepts. This suggestion is about passing -cmd options to controls after we've invoked a menu option which opens a form. The current suggestion is specifically intended to "drive" forms, allowing a UDT or other external process to fill in the fields on the Transform or Analysis dialogs, clicking OK, etc.
.dan.g. wrote: iamstarbuck wrote: Might we be able to work toward an extension on -cmd which allows for ... entry of data into fields ...
This is feasible but could create enormous future compatibility issues because it makes it harder for me to make subsequent changes out of fear of breaking existing scripts.
I would only propose this in a way that's future-proof. That said, because this is a form of programming, it must be subject to the common scenario where a base platform changes and functionality built on that must be updated.
More specifically, in order to set the value of a set of radio buttons, the controls need to be identified. Using the internal code control names doesn't allow you to change your names, so that's out. Hardcoding to labels to find controls is language-dependent, so that's out. But you do assign menu options a 5-digit ID, and to keep this consistent perhaps you could assign a 6-digit ID to controls. So in the Transform Tasklist dialog, (menu item 33024), we have a Title textbox and a Date checkbox. Let's assign these numbers 101001 and 101002 respectively. Those IDs will never change for these controls and if the controls are ever removed their number will be deprecated. So a UDT might include the following:
-cmd 33024 -fo "101001/My Title" -fo "101002/1"
The new (proposed here) switch -fo passes both the FOrm ID and the value. Since all FOrm IDs are 6 digits, the delimiter between that and the data is irrelevant. For Boolean values, 1 or 0 can be used (or T/F or Y/N).
All switches are operated upon in the order found. Unspecified controls use normal defaults which might come from the INI, so if there is any uncertainty about their value, they should be specified. After all of the -fo switches fill in the form, the OK button needs to be clicked. That's just another control with an ID, let's say 101021, and just invoking that from the command-line defaults to clicking that button.
-fo "101021"
Clicking OK there brings up the Save Transformations As dialog. However, since we're using switches, that form doesn't need to be launched on the click of the OK button. An ID can be allocated for the file path for the resulting file, let's say "101025":
-fo "101025/c:\my path\file.ext"
How might this work internally? Well, one approach would be to pre-load a buffer, fire events, and when a control event gets fired, load the value from the buffer. However, if the values are pre-loaded then a dialog doesn't even need to be opened, so there's no need to fill in controls. The values can be passed to the appropriate handler (transform, analysis, etc) as though they had come from a dialog.
This doesn't need to be done across the entire app. Maybe just try Transform or Analysis and see how that goes. Maybe expand to Import/Export later. Since the same controls are used in different pages, porting to other dialogs might be easy once the pattern is established. Now that I think about it, those four functions are the only ones I can think of where this feature would seem to have value.
Is that future-proof? I think so. If you add another control, like a fourth option on a three-option radio control set, that's just adding a new control, not changing existing FOrm IDs. You can move things around and change text and this all still works.
In day-to-day usage, we would be able to simply click a toolbar icon to invoke a UDT that generates a common report. That completely eliminates opening dialogs, confirming file over-writes, etc. It also facilitates getting reports from the command-line (and thus other apps) which we currently cannot do. So rather than adding command-line switches to generate each possible report, with this functionality we can drive the app using a single new switch for current reports, imports and exports, and for any new functionality like this that gets added later.
|
|
|
|
|
I'm sorry Tony, but this is a not a direction I am intending to take TDL, where the entire app can be automated.
If you document specific scenarios that you actually need to solve your real world problems then I will think about how best those can be met but I'm not writing a whole system based on a possibility that someone might use it.
|
|
|
|
|
Fair enough. The problem I'm trying to solve is that transforms and analyses are manual operations requiring a number of clicks. With a number of different reports for different clients, this effort can be rather time consuming. The thing is that each client wants specific kinds of reports which I need to remember and then manually configure in each report request. I'd much rather click a toolbar icon for a UDT to generate one or more client-specific reports as needed. This would also allow me to get someone else to generate reports without having to document the nuances of each client/report permutation.
To solve those specific problems, might we be able to get command-line switches which will pass all required values to just those two functions? Not "the entire app".
Examples for tr = transform and an = analysis
-tr "Title|Today|stylesheet.xsl|Filtered|CU|AllAtb|TargetFile.htm"
-tr "Title||style2.xsl|All|U|Comments,Percent Complete,Status,Task ID"
-an "ThisMonth|ByDay|CSV|TargetFile.csv"
-an "08/01/2015,08/31/2015|ByWeek|XML|Target.xml"
The values are subject to better definition but I've used the following conventions here:
- For radio buttons there is a set of values like Filtered or All.
- Custom attributes are named and separated by commas.
- Use "C" and "U" to indicate list includes Completed and/or Uncompleted tasks.
- If the period for the report includes a comma, use the delimited values as from/to dates.
All of this can be done without a change to the UI. The values can be parsed, converted, and assembled into a method call to the transform or analysis functions, exactly the way the form/dialogs would do it.
If this is accepted as good way to do this, perhaps the Import / Export could be setup the same way with -im and -ex. I don't think there are any other dialogs like this where automation would be of value.
Thanks as always for the discussion!!
|
|
|
|
|
Thx Tony.
Now that I understand your needs better, I can see the obvious benefit of extending certain dialogs (Transform, Print, Analyse, Export) to support saving named configurations in much the same way that the 'Find Tasks' dialog already does.
This would have the added bonus of allowing less technical users to access this functionality without needing to configure complex UDTs.
|
|
|
|
|
That's an ideal solution. I'd still hope for a way to invoke a named transform or analysis from a UDT. That gives us single-click access to common reports. What I would do with that is to call a program from the UDT, passing in an ID for the kind of report I want along with the .tdl file path and .ini. This would allow me to lookup the name of the analysis that I want to do for the client associated with the list, and invoke a new command line back to TDL to execute that analysis. This way I don't need a toolbar button for every client, just for each report type: Time This Month, Time Since Last Invoicing, etc. The UDT I call might even kick off multiple reports - I commonly report to clients with more than one transform report and more than one analysis (which I reformat into a single Excel workbook).
Note that for analyses, we'd need a way to pass in a from/to date for definitions based on date range.
When we've nailed this down I'll create new tickets for feature requests.
Thanks! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
I've added variables into my XSL files to allow them to behave differently. As seen here[^] for example, I'm hard-coding my desire to see estimates in a specific report. This requires me to have a different stylesheet for each intent, with the variables set differently.
What I'd prefer is to be able to add name=value pairs into my transform request, and pass them to the XSL processor before the Transform. This can be done with the addParameter method, at least in MSXML3+, not sure about the MSXML2 used in TDL.
Further, because this data is fairly consistent per-tasklist/client for me, I'd like to be able to store the name=value pairs in the INI. I think this would be fairly elegant, since the parameters are based on the XSL, there could a section to define the applicable stylesheets:
[XSLTransformFiles]
XSL1=c:\path\to\mysheet.xsl
XSL2=c:\another\file\here.xsl
Then when a specific tasklist is transformed:
[XSLParams\ListName\XSL1]
pShowEstimates=0
pShowPriority=1
[XSLParams\ListName\XSL2]
pEstimateStyle=0
[XSLParams\AnotherListName\XSL1]
pShowEstimates=1
pShowPriority=0
The first section could be avoided entirely with this construct (if it's valid .ini syntax):
[XSLParams\my tasklist name.tdl\the xsl filename.xsl]
If that's not valid then perhaps a hash of the filenames or similar encoding would work to create a valid section key.
Looking at the CXmlFile::Transform method in XmlFile.cpp, it looks like this wouldn't be a tough fit.
Since this is operating at a programmatic level, I don't care about a UI maintenance interface for that. I'd be happy editing the INI manually and having those values transparently passed to my XSL.
I do not recommend that those values go into the tasklist itself, as (1) that would modify the schema, and (2) different users with different .ini files might have different preferences.
That said, as an added bonus it would be Really helpful if the Transform form would display a small grid with the name in column1 and the value in column2, so that the values can be changed on a per-execution basis.
Here's another way that could work
Rather than dedicating static sections and name=value pairs to the .ini, and logic to parse those sections, a UDT can be created which will inject the INI with a single section of [XSLParams]. On the next Transform, all of the params in that section will get added. The UDT (which I would write of course) will have its own datastore (maybe exactly what I defined above) and on execution will allow modification for the current tasklist which a specific stylesheet is selected. So, open the UDT, it gets the tasklist from the command-line, it opens a list of the related stylesheets, and on selection from the list it displays relevant parameters. On Save, the current .tdl ini is loaded with the values. That completely eliminates any requirement for a UI change and could reduce this part of it to a very minimal effort for Dan.
There are two issues with that so far:
(1) We need a parameter to pass the .ini filename to a UDT.
(2) We need the ability for a UDT to force a refresh of the .ini.
Uh, so what do you think? 
[Edit] Yet another (even easier) way to do this:
ToDoList gathers all required data, generates a temporary .xml file, then invokes the Transform method on the built-in MSXML control. What if there were an option so that right at that very point, a preference could be checked for an alternative processor? If there is, just execute it, passing the name of the .tdl, the .xml, the .xsl, and the target file (.html, etc) then return a true/success result. The external/custom routine can use its own datastore to decide how to do the transform using the provided data.
This would require absolutely no UI changes and only one new transparent name=value pair in the INI.
modified 27-Aug-15 20:32pm.
|
|
|
|
|
The last option is preferable to me but your claims of there being no UI impact make it sound as though you want me to slip it in unnoticed.
The approach I prefer is to spec it out properly with the necessary UI changes to the 'Importing/Exporting' preferences and then for me to consider it for 7.1.
|
|
|
|
|
My goal is to get more out of the software while minimizing your effort to make that happen.
As an example, perhaps the UI is already done via the UDT setup with some new arguments:
"$(pathName)" "$(iniName)" "$(xslName)" "$(transformTarget)"
Immediately prior to calling .Transform you can check to see if there is any UDT with $(transformTarget) in the argument stream. If so, just execute the UDT rather than generating the target.
|
|
|
|
|
iamstarbuck wrote: minimizing your effort to make that happen
I appreciate that. See my comments above[^].
|
|
|
|
|
.dan.g. wrote: It seems that the current problem/issue with transforming outside of TDL is that you lose all the selection/filtering/attribute options of the Transform dialog which are used to create the intermediate file passed to the transform code.
I was suggesting that the Transform process stay the same with the form and generation of the XML, but that rather than doing the transform in MSXML2 yourself, just execute a UDT. That will then read the selected/filtered tasks and call to do a transform with code similar to what you have. The benefit is that someone who wants special XSL features can get them without you having to update the built-in MSXML2.
Where this dove-tails with the other suggestion is that we would be able to provide the specs for the transform dialog from a command-line, TDL would generate the XML to that spec, and then, per above, another UDT would be called to operate on the XML.
|
|
|
|
|
Note that this suggestion is separate from the other one.
The other suggestion has been narrowed down to a possible new feature where we can invoke saved transform and analysis configurations by name, ideally with a UDT.
This suggestion is for transforms to call an external process to actually do the final transform rather than going through the internal MSXML2. So assemble all of the data into the intermediate .xml file and then invoke a UDT to process the data rather than doing the .Transform() internally.
|
|
|
|
|
iamstarbuck wrote: someone who wants special XSL features
As far as I can tell that someone seems to be just you 
|
|
|
|
|
 OK, most people see just the façade of ToDoList, and it comes with a few "stock" report formats. Some of us developers know what goes behind those reports - the XML and XSL. This allows us to extend the set of reports available. Now you have this guy who knows what it takes to make those static reports dynamic, so that people who have the reports don't need to be programmers to get them to do what they want. So if this one guy can get others to understand what the heck he's talking about, perhaps there might be more demand for "whatever it is" that he's asking for.
I'm starting to run out of approaches except to do a regular transform just to get the XML, then run an external routine, maybe from a UDT, to do what I want with the XML. There's that, or publishing the library  (best option now I think) ... or writing some C++.
If anyone else would like to comment, now would be a good time. 
Thanks for the discussion, Dan.
|
|
|
|
|
iamstarbuck wrote: I'm starting to run out of approaches
You've only run out of approaches where you seem to want me to most of the work!
|
|
|
|
|
See the screenshot in the report[^] in Twitter: "Couldn't read anything while updating in the changelog/progress window due to #HighContrast theme."
Given that there's only 140 characters in Twitter for a report and this one is fairly self-explanatory, I don't believe it's necessary to press for more detail.
And for anyone with a Twitter account, Follow Us[^]!
|
|
|
|
|
Can you or he submit a bug report to GitHub pls?
|
|
|
|
|
Yeah, I'll enter this.
Just to be clear, when a report comes in from Twitter or Facebook, it's more of a passive bit of information for us to process. It's tough to carry on a dialog to get more info. I will certainly do my best to validate such reports before presenting them here or to GH but we can't always ensure a set of reproducible steps. In other words, if someone here is reporting an issue that they found, then we can hope/expect to get a full set of info for a change, but if a report comes from "outside" then we can try to get more info, but sometimes we'll need to rest with whatever info we can get. And if that's not enough to actually process the request, so be it.
Thanks.
|
|
|
|
|
All good, I can reproduce this and will have it fixed for 7.0.2.
|
|
|
|
|
Created Issue#57[^].
The user requested a review of the view with the high contrast theme in general. (At least I think that's what he's asking as he's German but speaking English for us.) Uh, where is this theme? 
modified 1-Sep-15 14:45pm.
|
|
|
|
|
iamstarbuck wrote: Uh, where is this theme?
Right-click Desktop > Personalise > Scroll to bottom.
|
|
|
|
|
|
I have created some user specific searches / filter.
All these appear in the drop down box upper left side "Show" A)All Tasks B).... 0)Main Tasks )....
6)Info 7)Work Now 8)Work Planning and so on.
Now when I try to select a filter using drop down box the "box" jumps back to entry A) instead of selected filter 7). Steps to reproduce:
Set up a bunch of filters like 0) to 9) user specific.
Select filter A) : works
Select filter 7) : jumps back to entry A) and does not filter
Select filter 0) : works
Select filter 7) : now works and result is displayed.
Strange....
|
|
|
|
|
Tom Freier wrote: Possible Bug TDL 7 RC2
Do you really still use RC2?
is it possible to update to current version and try again?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
