|
Apologies . Haven't touched this for close to a year, and have forgotten too much! Forgot the node/attribute structure in the TDL file. I was treating the custom attributes like an attribute of the task. All working fine now.
Now to go to the next challenge - to output the custom attribute icon into the stylesheet. Any help welcomed.
zajchapp
|
|
|
|
|
I wrote some extensive code in the library to make it easy for a developer to identify and use the icon values. You/we/I can use this to extract icons into individual files which can then be referenced by img links or CSS via your XSL. It won't be long before this is out...
HTH
|
|
|
|
|
Around Christmas last year I got an image to display on a report via HTML. Took me a bit of messing around, as I am very much an infrequent programmer, and don't know these languages well. I didn't manage to get the icons working before work got busy again. I would be interested in this functionality when available.
zajchapp
|
|
|
|
|
In the 'header' of the XML you will find the custom attribute definitions (CUSTOMATTRIBDEF ), and then within each task there will be zero or more non-empty attribute values (CUSTOMATTRIB ).
ie. a specific task's custom attributes values will always be non-empty, hence your test failing.
As for why the attribute would appear empty, I've no idea, sorry.
|
|
|
|
|
See above. Had a bit of brain fade, so my apologies.
|
|
|
|
|
Looks like msxsl gets right cranky at what I think is a backquote. "’"
Error occurred while parsing document.
Code: 0xc00ce508
URL: file:Line: 63
Column: 39
An invalid character was found in text content.
Copied from a doc or CheckVist then imported / from clipboard.
I think it's 0x92 but I'm guessing. Hopefully the message editor doesn't munge things in the quotes above.
Perhaps something worth stripping out / replacing at text entry or at clipboard input. (Or something.)
modified 9-Nov-14 16:54pm.
|
|
|
|
|
Did you experience this error in TDL itself?
|
|
|
|
|
No. But ... reported as I expect (from what you've said) they use common libs between them.
Actually ... not sure if I'd notice - failure flips by so fast, if there even is a screen, at publish. Let alone I don't recall if error (codes) cause a failure popup.
In any case, not sure it matters - if something is going to make msxsl cranky, it can't be permitted to land there in the first place, and TDL is the keeper of the file content, as it were.
Or put in a somewhat different way - sleuthing out the issue involves opening up the .tdl in a text editor, which is not something I expect you want the average user to have to do to. At failure, it's a complete mystery and all but hidden to the user - there is no apparent way or what for what's not working. It will appear as a TDL failure, which is a conclusion I suspect you would prefer not to be drawn.
In the end, it's all a bit strange - given the plain text fields, obviously there is some sort of watchdog in place for non-'text' characters. My guess was 0x92 didn't make it to the 'special characters to watch for list'. Or the keyboard entry to plain text field and windows clipboard input mechanism aren't using a common watchdog.
Speaking of which ... I've noticed on a text (csv, e.g. \t delimiter) the first line of input is lost. Seems the assumption is the first line is the usual .csv field list, but that might not reasonably be true / present on a clipboard paste (tools/input).
In any case, thought I'd better send a heads up. If nothing else, perhaps someone searching the forum will see the heads up and be able to work through their issue.
|
|
|
|
|
Interesting.
Have run into this again on a different list.
Was able to see the problem does not exist within TDL's internal processing via print preview.
So, msxsl and the corresponding lib TDL uses must not be exactly the same. Note sure how much that matters if TDL encourages (requires) msxsl calls for any other list printing / transformation output formats.
In this case, problem turned out to be "s, as in '2" from corner'. 0x94
I do see an & in a comment that has been stored in the tdl as & - so no doubt the 0x92 and 0x94 are simply two missed characters in such text processing.
Problem is, the only way I can figure out how to sleuth such out is by text editing the .tdl file and taking out task lines one by one until the culprit is found. If anyone has better / faster suggestions to figure out what's killing things when this happens, I'm all ears! [XSL to the rescue! Mixed blessings, I suppose.]
At least this time the msxsl reported problematic line number was accurate.
Real issue is, I suppose - silent failure. User will note unexpected results, but have no idea as to where, why, or how to fix.
Bonus problem here is ... these comments were moved (cut and paste) from one task to another. But because of the tdl forms of
<task>{task stuff}
<comment>
comments
</comment>
comments repeated again
</task>
and the comments between and not taken out of the old task, msxsl still complains, and there is nothing visible within tdl for the user to fix. So in one of the occurrences of the issues in the file, it looks more like:
<task />
comments left behind
</task>
More completely:
<task>{taskstuff}
<comments>
2" from corner
</comments>
2" from corner
</task>
<task another task />
2" from corner
</task>
- and the bottom 2" text entry invisible to the user. (Being a comment since deleted from that task.)
Solution: Replace first two "'s above in .tdl with " and remove the (last) text from /> to </task> (which I wish wasn't there, but never mind that - goes back to needing both plain text and rtf comments, I suppose).
|
|
|
|
|
TDL has code to fixup tasklists if MSXML reports that they cannot be loaded. So this is definitely a difference.
_BS_ wrote: 0x92 didn't make it to the 'special characters to watch for list' Possibly not. I'll look into it.
_BS_ wrote: that might not reasonably be true / present on a clipboard paste (tools/input) You are quite right. I'll add an appropriate checkbox in 7.0 to control this.
_BS_ wrote: thought I'd better send a heads up You did good, thx
|
|
|
|
|
Hey ... if you're into that import/export code ... any chance you could add a back button to the second dialog?
Inevitably I change my mind, have to hit cancel, tools / import, discover I was right the first time, click next, second guess myself again ...
Also ... perhaps prepend "Title\n" to the clip area, or somehow other assume it from file? Perhaps, "If start of first line is not obviously a field title" do the same? I keep losing the first line of the input (being mapped to title).
Or perhaps a 'no headers, assume title' checkbox?
And perhaps rather than leaving first field mapping blank by default, default it to Title?
|
|
|
|
|
I don't recall if this has come up before, sorry.
We can filter tasks and then toggle to view all tasks unfiltered. That's a single custom filter.
But I find myself jumping between filters for what's currently active, what's in planning, what's been worked on recently, etc. So it would be ideal to have multiple filters for quick access. Perhaps an easy way to implement would be to add a Save checkbox to the filter bar. When checked, a new option would be added to the Show dropdown. To avoid conflicts, the default filters can continue to use letters while the custom saved filters would be numbered. When a saved filter is displayed, the related filter items are set and the checkbox is checked. If it's unchecked, the currently selected custom filter is removed from the dropdown list.
Gosh, I hope I'm not missing functionality that's already built-in.
Thanks.
|
|
|
|
|
I will be adding the ability to save filters to 7.0.
|
|
|
|
|
I am not sure what you mean by TDF.
Does this mean you will be able to create a filter in the filter bar, and then save it for future re-use? If so, that would be brilliant, especially if this also includes the custom attributes.
zajchapp
|
|
|
|
|
Just to add, I also find my situation similar in that the many times the tasks become many, such that it becomes difficult and even unproductive to actually find the data one is looking for(constant scrolling backand forth).
In addition to the filter, I truly think the ability hoist tasks in a separate sub tab of the same document - especially if the two panes can be juxtaposed would permit the user to quickly compare/view two parts of the same document
Also could you please clarify what you had meant about saving the filter as a url link? I asked if that feature was already available or not, but didn't receive a clarification onthat
|
|
|
|
|
Member 11190275 wrote: Also could you please clarify what you had meant about saving the filter as a url link? What I meant was that I could create a new protocol so that filters could be referenced in the comments fields in the following way: tdf://<filter name> .
|
|
|
|
|
create a new protocol so that filters could be referenced in the comments fields in the following way: tdf://<filter name>.
That would be absolutely great! exactly what Id hoped for
|
|
|
|
|
Apologies if I am mis-interpreting, but you do know about the ability to create and save filters via the Find Tasks dialog?
zajchapp
|
|
|
|
|
Oh dear, that looks exactly like what I was describing. I think I've used that in the past and it's not just something in my "mind's eye" but was actually in my eye some time ago.
I've experimented with the functionality but I really don't understand some of the filters. Like what's expected in the relative modified date field? Any filter I create seems to return zero tasks, or seems to combine with the last save, or ... something... I'll need to experiment with creating, saving, and then applying the filters.
But yes, it looks like this feature is already in there!
Thank you VERY much!
|
|
|
|
|
No problem at all. It sounds as though we will be able to save filters based on the selected filter state in V7, so that is fantastic, especially if the custom attributes are included in this. It would almost totally replace the need for the filters in 'Find Tasks'.
For the relative dates, if you want this month, type 'm', for the following month 'm+1' and so on. 'd' is for day, 'w' is for week etc... And I can't remember if 'm' is the start of this month or the end of this month - trial and error needed.
I have a set of filters I have created, so I can incorporate the custom attributes. The main difficulty currently is that you can't specify parentheses, so complex filters can be a challenge to design and input. Not that I am grumbling...
zajchap
|
|
|
|
|
I've made a few comments over the last couple months about separating different kinds of comments but I haven't thought about it enough until now to articulate the concepts.
I think there are four kinds of comments:
1) Comments about a task. This is part of the definition, the spec that tells us what the task is.
Comments on task activity. This is where we use the ctrl+D to document what's been done on a task as it happens. There are actually two kinds of activity comments:
2) Notes for people working on the task so that there is a detailed log of what's going on. These notes are not published in reports to clients or management. I'll refer to these as Internal Activity Comments
3) Notes for clients/management about general activity, issues, milestones. These notes are for reports. I'll refer to these as Public Comments.
4) Comments in time logs detail why the time is being logged. This could be for purposes 2 or 3 above, so we'd have Internal Log Comments and Public Log Comments.
How might we get from here to there?
We currently have two comment fields, the task comment and the time log comment. One quick/cheap way to separate comments is to use an unusual character in the text (alt-sequence) to separate Internal from Public comments. In XSL we can parse either side for specific report types. I do this to parse the first line of a comment as a task summary, using the EOL character as the delimiter. My code then checks the result to see if it's null before wrapping it in HTML. I can share my XSL. For time logs, the single comment field can similarly be parsed by a macro or other code that post-processes the CSV data. This DIY method can be used by anyone now with some discipline and XSL changes, but requires no effort by Dan.
Another mechanism requires code changes. Keeping the Comments field for all who use it, three new fields can be added to the tasklist schema for anyone who wishes to separate the concepts: TaskDescription, TaskInternalActivity, and TaskPublicActivity. Like Comments, each of these fields would be optionally PlainText or RTF. It would be up to anyone who desires to use these field to copy relevant parts of the existing Comments field to whichever field they wish. The general purpose Comments field can still be used by each individual for whatever purpose they wish, as it's used now, or in addition to the other fields. The UI would need to accommodate up to four comments blocks. The time log would also have another comment box added to separate Internal from Public comments, and the CSV would get a new related column.
As I sometimes do, I'm presenting a challenge that I have just to see if others have the same challenge. I've presented my thoughts for a solution but I'd be interested to know what others do or think.
Thanks for your time.
|
|
|
|
|
I think 'comments' are sometimes a misnomer. Some times 'Notes' are a better name.
There is an additional comment 'type' - app / task / maintainer comments. "Set up this task with these fields ..."
I think the various comment types reflect more on the task type than on the comments. Arguably anything with sub-tasks are summary tasks, and only summary information should be present. Thus task execution comments might not belong in that record, but in a sub-record.
Arguably, for each comment type you note, there should be a corresponding sub-task within which the associated comment type would be entered. [You're almost suggesting a hierarchy of comments within a record, when that hierarchy organization is already inherently present at the task level - wheel reinventing?] Milestone, for example, is typically a standalone task. Or a summary task. (Bottom up vs top down, almost, depending upon your personal viewing preferences.)
You also almost seem to be suggesting comment tags. e.g. Maintainer tag / comment, Project Manager tag / comment, task executer / comment [e.g. time spent journal log comments]. For that moment's use case, apply a tag filter and you're there?
It feels like you are groping towards sub-comments. If you instead consider summary tasks as the task, providing you a sub-hierarchy of task and therefore comment types, are you not already where you're trying to go? [I do get, given your musings, that the presentement that you are looking for may not currently be present - but is it possible that that is because of some lack in filtering / presentation facilities for where you're trying to go, which would be a different beastie? i.e. Enhancement request is not for comment sub-hierarchy but for a 'filter by tag plus other considerations' combination.]
More succinctly - treating sub-summary tasks as the task definition, and applying tags, is what you're looking for not already present?
|
|
|
|
|
Thanks @_BS_. I've thought about your comments carefully, mixed thoughts on each reconsideration. I do use a hierarchy of sub-tasks (project level task, parent task, child task) where the parent task is a container, not actually used for logging, and thus can be used to contain task definitions. One can assume here that the child tasks would be used purely for tracking activity, and their comments would have the related log data that I describe.
However, each child task needs its own description - why does this task exist such that it will be worked on separately? That can't always be summarized in the top line. So using your scenario I would need to use these child tasks as definition items and do my actual processing on grandchild tasks. In other words, each task that gets actual work would require an immediate parent to define that item. This doubles the number of task nodes in a list.
The problem is that while the structure is sound for some folks with some applications and with some additional handling, this is an imposed structure which may not conform to existing lists.
To back up a bit - To me, a task has many fields, and I find myself using the single Comments field for multiple purposes. I think it's quite reasonable to propose additional fields on the task to support this application, because I'm guessing that while most people haven't yet considered this to be an annoyance, now that we're talking about it I'd think some folks would see the value in enhancements in this area.
Here's another option - supporting additional data types on Custom Attributes: Text Area and Rich Text Area. Right now we just have a small text field suitable for tag-like text. I'm wondering if people use that for more text and just accept that they can't see the whole thing. Rather than having a new standard field to separate descriptions from comments, I'd be happy creating custom attributes for my own purposes. If course we'd also need another mod to set which custom attribute are displayed in the grid, and the edit block would need to adapt to support larger custom fields.
So in my initial note I proposed adding new fields and structuring the Comments field for these purposes. @_BS_ has proposed another mechanism. And here I propose yet another. I'd be interested in other comments and proposals.
|
|
|
|
|
FWIW, I really only use the first two types mentioned, and I don't have need for reporting to customers or bosses using TDL.
My notes are mainly to more carefully explain the task and to provide additional background to it (Notes or links to files/emails). This is mostly presented in the parent tasks.
I also sometimes have a small list of sub-tasks in the comments that I don't feel warrant their own 'real' tasks, which live in the relevant child task.
I also use TDL as a structured note taking application.
Bearing in mind I don't use the system the way you do (and hence may not understand some subtleties), I see it slightly differently. I do wonder whether the first two are different enough to warrant distinguishing them.
To me it comes down to separating by audience. In this case, 1. People working on the task, 2. People you are reporting to about the task (i.e. Internal vs Public). Each audience may have description, background, work details, or time log notes information (is there really any need to separate these out?).
So I wonder whether you only need 2 comment types /sections to achieve what you are after (Internal/Public). I can't really comment on how this might be implemented, but the suggestions above seem possibilities.
PS: I'd be keen to see you comment manipulation code...
zajchapp
modified 9-Nov-14 5:21am.
|
|
|
|
|
Dan,
A few questions, using RC2:
- Not sure if this is intended behaviour. I am finding that when in Listview and I change the Filter, the Sort is lost and needs to be reapplied - bug or feature?
- I noticed that once the task is checked off, the status is set to 'Complete', and cannot be changed. Initially I expected the status value to just be changed, rather than locked down. I have had occasion to want to change it to 'Cancelled'. Comment?
- Is there a way to 'hide' task references when applying a filter? They are useful to see for some task management processes, but are not useful for others. Could this be added as an option perhaps?
- Something from a long time ago, the Gantt chart still fills the bars in as white when the chart is set to using default colours, and there is no colouring. Ideally the bars should default to black or grey rather than white in this case in my opinion...
zajchapp
|
|
|
|
|