|
Apologies, my bad (maybe, still have to check).
In my testing that lead to the OP, looks like I was saying select first window, while I was thinking select first tab. My bad. Even if not not working, there was only one window, so ...
I discovered this in testing under windows (thus maybe means have to go back and check under linux again at some point).
However, making a better choice of -cmd 32953 (Next Tasklist - Ctrl-Tab), under windows, opened up a 2nd instance of tdl instead of shifting the current list to the first one. (The todolist.cmd myfile.tdl -f "my2file.tdl|my3file.tdl" leaving me on the last tab.)
Permit multiple instances is checked.
This reveals a potential enhancement consideration: Although there are codes for windows 1 through X, I don't see equivalents for Tabs 1 through X.
Although it is not reasonable to have X number of keycodes (how many is the right number?), it might be reasonable to have codes for the first and last tabs. Presumably consecutive next/last tab cmds can get you where you're trying to go. However, feels like something to set absolute position, to then use relative motions, makes sense.
|
|
|
|
|
_BS_ wrote: I don't see equivalents for Tabs 1 through X. Indeed, until now you can only select by tasklist filename. And since 6.9 will have drag'n'drop moving of tabs, it probably makes more sense to stick with keying off the filename.
And 6.8 should search all open instances of TDL to find the one containing the named tasklist.
So if you run TDL with an already open filename, it ought to find the correct instance, bring it to the foreground and select the appropriate tab, after which the chosen command will be applied.
This leads to the 'rule': Don't run a command unless the tasklist is also specified. I haven't looked at the code but it's possible I already apply this restriction.
|
|
|
|
|
OK, it's not obvious that a tasklist need be specified. Nor is (was) -cmd without a tasklist complaining about the lack of a tasklist.
In essence, -cmd allows the creation of (keystroke) macros. But macros aren't normally tied to specific documents. At least not in other apps I've seen. Hmmm. I'll have to think about that.
|
|
|
|
|
Is there a way to have titles wrap to the window rather than having it scroll?
|
|
|
|
|
Unfortunately the Windows tree widget does not support title wrapping.
|
|
|
|
|
I am setting up a .cmd script to help my users get up to speed with TDL a bit faster.
I've written a small bit of 'TDL in our environment' introduction (a tasklist, of course).
So the .cmd calls:
start /min todolist.exe localintro.tdl -v -f "Introduction.tdl|ToDoListDocumentation.tdl"
works well ... except, the user is left on the last tab. Although I could reverse the file order, I'd like to keep the tabs in a logical order of 'us', 'quick help', 'deeper help', and have the first tab be the current one.
(Bearing in mind, your mileage can vary for yourself - if you close TDL in your own environment, reopening it will bring you back to your last state. This change won't impact you.)
(Whereas in my case, each user will be bringing up this help for themselves, fresh, each time. This 'group' of lists is segregated off with its own .exe and .ini files.)
So, could the use of -f leave the user on the first tab, not on the last task list loaded tab?
|
|
|
|
|
_BS_ wrote: So, could the use of -f leave the user on the first tab, not on the last task list loaded tab? I'll see what I can do.
|
|
|
|
|
THANK YOU! For addressing this in 6.8.4.
|
|
|
|
|
Hope you holidays are filled with all you favorite things this Christmas ... and all the happiness you could wish for.
Happy Christmas
|
|
|
|
|
|
Hi Dan,
Merry Christmas and a happy New Year!
Included is a very big thank-you for all your work and support .
.!, .!,
~ 6 ~ ~ 6 ~
. ' i ` .-^-. ' i `
_.|,_ | | / .-. \ | |
'|` .|_|.| (-` ) | .|_|.
/ \ ___)_(_|__`-'__|__)_(______
/`,o\)_______________________o_(
/_* ~_\[___]___[___]___[___[_[\`-.
/ o .'\[_]___[___]___[___]_[___)`-)
/_,~' *_\_] [_[( (
/`. * *\_] [___\ _\
/ `~. o \] ;( ( ; [_[_]`-'
/_ * `~,_\ (( )( ;(; [___]
/ o * ~'\ /\ /\ /\ /\ [_[_]
/ * .~~' o\ ||_||_||_|| [___]
/_,.~~'` * _\_||_||_||_||___[_[_]_
/`~.. o \:::::::::::::::::::::\
/ * `'~.. * \:::::::::::::::::::::\
/_ o ``~~.,,_\=========\_/========='
/ * * ..~'\ _|_ .-_--.
/* o _..~~`'* o\ ( (_) )
`-.__.~'`' * ___.-' `----'
":-------:"
\_____/
Cheers,
Jochen
|
|
|
|
|
Awesome picture, thx mate.
|
|
|
|
|
Updating prior post to:
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml" indent="yes"/>
<xsl:strip-space elements="*" />
<xsl:template match="TODOLIST">
<html>
<head>
<title>SAMPLE PAGE TITLE</title>
</head>
<body>
<h2>HELLO WORLD</h2>
<ul>
<xsl:apply-templates />
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="TASK">
<p><xsl:value-of select="@TITLE" /></p>
<ul>
<xsl:call-template name="fix-breaks">
<xsl:with-param name="text">
<xsl:value-of select="COMMENTS"/>
</xsl:with-param>
</xsl:call-template>
</ul>
</xsl:template>
<!-- Thieved from TDL Sample Stylesheets - THANKS! -->
<xsl:template name="fix-breaks">
<xsl:param name="text" />
<xsl:choose>
<xsl:when test="contains($text,' ')">
<xsl:value-of select="substring-before($text,' ')" />
<xsl:element name="br"/>
<xsl:call-template name="fix-breaks">
<xsl:with-param name="text">
<xsl:value-of select="substring-after($text,' ')" />
</xsl:with-param>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$text" />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<!-- <xsl:template match="text()"></xsl:template> -->
<!-- - if the above line is included, the lines below are superfluous. -->
<xsl:template match="METADATA"></xsl:template>
<xsl:template match="COMMENTS"></xsl:template>
<xsl:template match="CUSTOMCOMMENTS"></xsl:template>
<xsl:template match="CATEGORY"></xsl:template>
<xsl:template match="ID"></xsl:template>
<xsl:template match="PERSON"></xsl:template>
<!-- Superfluous lines end. -->
</xsl:stylesheet>
- does a reasonable job. For a basic start, with comments.
However, spurious text from the malformed XML (mixed content) comes out. Typically comment text that lies where it does not belong. (How it got there remains a mystery.)
If I uncomment:
Then all the spurious nonsense nicely goes away, however, the comments lose their line breaks.
Anyone know how to munge the above into the equivalent of:
I've tried playing with priority, e.g. <xsl:template match="{Blah}" priority="99">, but I don't understand enough about XPath / expressions to come up with the correct logic in any reasonably time frame. (Which is to say, the syntax is fine / accepted, but the desired impact isn't happening - comments with line breaks. This line is still swallowing the input / preventing the comment handling code from being triggered.) Help!
I've also tried:
match=text()
xsl:if match="COMMENT"
apply-templates
but again, I'm just not getting the syntax / priority / code right - the comments continue to come out without line breaks.
<ARGH!>
Suggestions?
|
|
|
|
|
I am seeing a lot of spurious text in the .xml. I have yet to pinpoint down the cause. I expect some of it is legacy xml leftovers (e.g. Schema changes from @COMMENT to COMMENT.) A simple new task list, enter comment, save, is not producing the spurious text. Spurious being outside of tags.
e.g.
<TODOLIST ...>
<TASK ...>
<COMMENT>Here is a comment.</COMMENT>
Here is a comment.
</TASK>
Here is a comment.
</TODOLIST>
This is causing the stylesheet no end of grief, encountering text outside of tags.
Could a Tools / Rewrite (Clean up?) TDL file menu item be created, please?
{I would guess this is simply a link into the Save As code.}
(This would also have the impact of reforming legacy lists to current internal schema - no bad thing.)
[Arguably, at list load, such now non-standard contents could be detected, and the user prompted to run this cleanup.]
The above would become:
<TODOLIST ...>
<TASK ...>
<COMMENT>Here is a comment.</COMMENT>
</TASK>
</TODOLIST>
Although it could be argued that there are programs out there that could independently of TDL do this, the argument is false - only TDL knows what's spurious / currently valid, let alone what to do with it. (e.g. Spurious text is likely comment duplication - only TDL could know that.) Merely running tidy on it wouldn't do it, it may format / indent the file 'correctly' but won't know what is removable / duplicated. And any such argument works only if there is a rigorously defined and adhered to schema, which there is not. Even if there were, such a program would have to prompt '{this} is unexpected, what would you like me to do with it?', and the user won't know - doing nothing for fear of losing content.
Much better for this to be within TDL itself.
Sanity check: Code edit a handy .tdl file - I expect you will be able to duplicate my observation of the presence of spurious text.
|
|
|
|
|
Does anyone know: Is such content called 'mixed content'?
- know how to tell a stylesheet to ignore it?
|
|
|
|
|
I have often wondered about the apparently repeated text in the tdl file. I thought I had seen this behaviour in newly created files though. And this goes for other subnodes, like PERSON as well as comments.
And at one point I am fairly sure I removed some in a text editor, but TDL didn't like the result.
|
|
|
|
|
Thanks. If you see such / can repeat it, please report it so Dan has something he can put under the microscope.
If he can repeat it wasn't here and now it is, when I do these actions, he's got something he can beat upon. Without it not so much.
Your observation, particularly in the absence of such evidence, I think just reinforces the usefulness that a cleanup button would have.
Regardless of when or how the out of band text arrives, cleaning it out would provide a solid new zero point, and reduce the level of insanity stylesheet writers have to go through.
I suspect, as well, that it would be easier to corral such cause and effect actions and give Dan something to look at - "File zeroed. Added a task, this result."
Particularly if such a button produced output of the 'found this unexpected value' to know if / when / what was discovered. Let lone a final 'Fix, no fix?' query.
If we think of this sort of like a 'chkdsk for xml',it could also provide / wrap up a diagnostic package that could be submitted to Dan. Before / after cleanup files, and cleanup button log files.
|
|
|
|
|
_BS_ wrote: If you see such / can repeat it, please report it so Dan has something he can put under the microscope. Yes please.
I don't produce the XML directly myself, rather indirectly via the MSXML.dll component, and the XML is created afresh every save.
However, that doesn't preclude me from having made a mistake.
|
|
|
|
|
Fair enough, but that just reaffirms the need for an XML cleanup button. Be it legacy or cruft creep.
It feels like (I'm guessing), you use the .dll to load into a memory structure.
Then when done, you tell it to write / close the file, pointed at that memory structure.
What I can't divine is, if there is cruft creep, it's somehow staying in there / coming along for the ride.
The only thing I can think of is (upon 'Cleanup XML' button press), create a new xml memory structure via .dll call, tdl code call copy from 'old' to 'new' and have it write the new structure, not the old.
The copy call would be tdl code line by line, field by field, old db to new. Thus old cruft couldn't come along for the ride.
Code wouldn't be write this field / byte, would be load this record, write that record.
At the least the code would provide a internal tdl development database sanity check. And quite probably most of the bits are already present. (Open db, close db, open/close/copy record, that sort of thing.)
|
|
|
|
|
It would be useful to be able to call a user defined tool upon save, not just export. (But export upon save is itself a REALLY cool feature, thank you!)
So, currently, I can cause a save to trigger off a 'publish update' to an .html file.
However, I intend to publish in two versions - one with comments, and one without.
Which I can put into a user tool to call a batch file to have msxsl run both transforms. (Never mind the inanity of this - I don't see any other way to do it. And there is no way to call TDL from the command line to run the user tool.)
- but I can't auto trigger that tool upon save.
Thus this request.
Arguably, I can batch this, perhaps within a .cmd script that first calls TDL to maintain the list (thus the discovery of the relative file path problems), however that script will always run the transforms rather than only upon save. .html time stamps will continually move, even though no actual data / list change has taken place. (Assuming the user was just looking at the list / didn't make any actual changes.)
-----
It may be worthwhile considering the further expansion of this functionality:
- upon save trigger, (optionally) ask user if they would like to view it?
- upon save trigger, (optionally) then ask user if they would to print it?
- problem: given the above, which form (comments or not) does the user want to view/print? (No way for TDL to know.)[This applies to a user tool call, not an export only call.]
= taken more generically, this becomes: 'perform these actions upon save'. [The specifics of any such user interface for such escapes me.]
~ in the mean time, for me, I could handle this by the user tool script (.cmd, .vbs?) - if it could but be triggered upon save.
|
|
|
|
|
_BS_ wrote: It would be useful to be able to call a user defined tool upon save I'll add this to 6.9.
|
|
|
|
|
Open TDL, no tasklist specified.
Tools / Preferences / Enable '.tdl' as a file extension for tasklists - unchecked
File / Save Tasklist As - Save as type: == Unicode Tasklist (*.xml)
Tools / Preferences / Enable '.tdl' as a file extension for tasklists - checked
File / Save Tasklist As - Save as type: == Unicode Tasklist (*.tdl, *.xml)
* the addition of *.tdl being significant / the difference.
From (Wiki) prefs
Enable '.tdl. as a file extension for tasklists
Allows you to open tasklists by double clicking them in Explorer.
Note: This will write a key to the registry.
Note: if you intend to copy your tasklist to your website then be aware that some XML parsers will not recognize your tasklist unless it has a .xml extension.
Problem:
(1) In essence, checking that preference makes THIS todolist.exe the one associated with .tdl files.
- but I could run many todolist.exe's in many different directories, or of many different versions.
= I will have only 1 'production' version of todolist.exe though, and nothing else should touch that association.
~ all bets are off for even more complex situations / users - they're on their own. If they got this far, they know how to roll with it.
(2) There is no direct association between what explorer uses to open .tdl files and what files are .tdl files. i.e. .tdl is always a .tdl file regardless of the explorer association. In TDL's mind, at least. A conflicting app also using the .tdl extension is that app's problem. (Presumably the user will avoid opening the other app's .tdl files in this app, and vice versa. If they do, their problem - they likely won't more than a few times before always being mindful of the issue.)
(3) Which todolist.exe currently has the association? It's not apparent to the user.
Suggestion: Beside that spot in prefs, put a button: Associate this tdl in explorer. (That way when it's the wrong one the user can go to the right one and repress it, never doing so in any other todolist.exe / being able to recover if they do so accidentally. Not to say the same effect isn't accomplished by un/checking this box, merely that a separate button is more user friendly / intuitive / apparent.)
Solution:
All file interaction dialogs, save as, load, whatever, should ALWAYS include the .tdl file type. This preference setting should have no impact upon file display.
- arguably, if all file dialogs include *.tdl, this preference should not be a checkbox, but a button, as above. Perhaps coloured appropriately if this .exe instance is the current handler. Green = Yes, Red = Not. With same said textually afterwards - for some reason I personally always get the colours backwards.
[By button I mean same size element / icon as current, but instead of being checkable, being pressable. This preference is more an action than a setting?]
Alternate:
Create another pref to always list .tdl files or not. (But I don't think that is necessary, always show .tdl files - if you're using the .xml extension instead, it will simply never show any .tdl files - there won't be any. If they do exist, such a user probably wants to know about it - it's likely an oops.)
Confluster:
Someone in a multi-TDL environment, e.g. Work and personal will -
(a) Want only one of them to be the default .tdl handler.
(b) Not see their .tdl files in file / open in the other. == Frustrated user / extra support calls.
(c) Be trying to keep .ini settings separate, and may want no (TDL set) association in explorer (so that designated list open pathways must be used, to keep required .ini/.tdl file association pairs intact). But still, in all cases, if they go file/open, they expect to see .tdl files listed.
[It would be, in almost all cases, insane not to assume a .tdl file is a TDL file - the reverse is not true, not all .xml files are TDL files. Insane in the sense of pointlessly creating a perpetual point of user confusion - a .tdl file is a TDL file, but is this .xml file a TDL file or something else?]
All file dialogs should include *.tdl.
CDN$0.02
-----
By extension, the above may also apply to "Enable 'tdl://' as a url protocol", but I haven't investigated.
- it would not be unreasonable to always treat tdl:// as a protocol. It should always be, in TDL's mind, at least - representation in other programs is the other program's problem. As a protocol if only for formatting purposes - e.g. underlined and/or italicized.
- the same argument applies as above - just because tdl: is a protocol (and displayed as such), doesn't mean -this- instance of TDL is the desired handler.
So, tdl: should always be displayed as a link, just like *.tdl should always be displayed as a TDL file. This preference setting shouldn't impact that. (Assuming the purpose of the setting is to bless this instance of TDL to be the handler. Thus it too could be a button, as above.)
- whether or not links are displayed as such is a different issue. Perhaps even another preference setting. (I hate it when LibreOffice displays every e-mail address underlined, when I'm maintaining a list of e-mail addresses, never intending to click on one and begin composing a message.) But such a setting is generic to all links, not TDL links in particular. Display, or not, shouldn't be a side effect of this particular preference.
Thanks for listening.
|
|
|
|
|
The tricky thing here is that TDL was written as a portable app, and having '.tdl' as a recognised Windows file type and/or 'tdl://' as a recognised Windows protocol requires writing to the registry which is non-portable.
Also, some browsers will not load an XML file unless it has the '.xml' extension.
I'm happy to revisit these decisions but it's not cut and dried.
|
|
|
|
|
> and/or 'tdl://' as a recognised Windows protocol requires writing to the registry which is non-portable.
Good point, but I don't think it applies to what I'm saying. It does point out that I didn't well cull out that use case.
(1) What I am saying for the preferences is that whether .tdl files are listed, or tdl: urls underlined, is a separate beastie from the preferences. Within .tdl itself, .tdl files should always be listed, regardless of preference setting, and tdl: links underlined. And the .ini can reflect that. To your point, whether the registry does is a wrinkle to be ironed out, but TDL itself and its .ini can be clear on that.
- but I take your point that file registrations / url associations touch the registry, and that may not be what is desired at that point.
- neither of which impact .ini, nor display of anything within TDL itself. Largely, these associations / registrations affect non-TDL use of such files / protocols.
(2) A file protocol in text is a file protocol in text, and should always be underlined. (The pref should actually be whether to underline file protocols at all. Perhaps with an accompanying button, as described, to register this TDL as the handler. But these are separate / distinct / disconnected concepts, being bundled within the same preference setting.)
(3) I would have thought all file dialog windows would be called via something like OpenFile( window handle, initial file display filter). All I am suggesting is that filter should always be '*.xlm;*.tdl' - which I would have thought was under TDL control / specification. (That such a filter reasonably covers all cases is explained in prior.)
So: these 2 particular preference settings are bundling 2 distinct things within the same boat, and the 2 distinct things aren't always both on or both off - one on / one off is reasonable. [e.g. Don't register file type, but do list *.tdl files in file dialogs.] File dialogs should always include a *.tdl filter present (if the current filter is not *.*) - which I would have thought is under TDL coding control.
|
|
|
|
|
Hello Dan,
If you could put up with one more "interesting idea" from me, I've got a pet wish for the comment field: the addition of an editing command button for a dynamic-length horizontal-line separator (like what Evernote has for its editing window). Such a separator would be very useful for quickly marking off a large amount of text in the comment field into manageable sections.
Currently one can draw dividing lines by repeatedly hitting the hyphen or underscore key, but, besides being a bit hassleful to produce, these keyed-in lines also cannot change their lengths according to the changing widths of the comment field, so that they would sometimes double over, and sometimes become too short for the resized comment field.
Many thanks again for your consideration,
NT
|
|
|
|
|