Info: ToDoList 7.2.RC10 is available for download

[.dan.g.]

Hi Everyone

Get it here or if you have any previous 7.2 pre-release you can update via 'Help > Check for Updates'.

Please only add bug reports and comments about 7.2 to this thread. 

Comments elsewhere will be ignored.

What's Changed from 7.2.RC9:

• Fixed 'View > Clear Filter' to also clear droplist checkbox history
• Fixed 'Drag and Drop' performance
• Fixed changing 'Custom Attribute' data type to remove unsupported 'Features'
• Fixed rare deletion of tasklist during processing of faulty backups
• Fixed loading of custom task images
• Fixed incorrect restoration of 'Task Tree/ListView' column/comments width
• Fixed importing of 'Outlook' 'Importance' field to 'Priority'
• Fixed 'Task Tree' expansion bug
• Fixed 'Allocated To' filter matching
• Fixed 'Undo/Redo' after multiple task move
• Fixed 'Filter Bar' flicker when switching to/from a filter
• Fixed 'Kanban' handling of filtered 'Custom Attributes'
  
• Added 'Reload Icons' button to 'Edit Task Icon' dialog
  

Enjoy!

[mikro]

Bug/Feature: 'Find Tasks' filtering rules vary inbetween different tasklists

Hi Dan,

using the timemachine my post now is:

= = =

Hi Dan,

thank you for another update!

I just stumbled about this issue that the same filter setup in the 'Find Tasks' window shows two different definitions for two seperate tasklists.

Btw. I use the same filterlogic for all my tasklists so filters are intended to be the same for each one of them.

Tasklist 1

Filter 'Turnus Intern Log'

Tasklist 2

Same Filter 'Turnus Intern log'

(after switching to another filter and back again)

 

I can image your Intention to be

• The filters should be the same for all tasklists => then we have a bug storing and loading the filter criteria

By the way, I just noticed that if I

• change the tasklist with open filter task Dialog
• do not change the loaded filter
• modify the filter and save it under the same name

the changes in the filter are not saved.

I striped my two projectlists from their contents and still can reproduce the issue.

cheers

Mikro

[.dan.g.]

Hi Mikro

Can you try to fix up the images please?

On Thursday, 25 October 2018 19:38:23 UTC+11, mikro wrote:

Bug/Feature: 'Find Tasks' filtering rules vary inbetween different tasklists

Hi Dan,

thank you for another update!

I just stumbled about this issue that the same filter setup in the 'Find Tasks' window shows two different definitions for two seperate tasklists.

Btw. I use the same filterlogic for all my tasklists so filters are intended to be the same for each one of them.

Tasklist 1

Filter 'Turnus Intern Log'

Tasklist 2

Same Filter 'Turnus Intern log'

(after switching to another filter and back again)

 

I can image two intentions of yours

1. The filters should be the same for all tasklists => then we have a bug storing and loading the filter criteria

1. The filters should be individual for all tasklists => then clearing and loading the filters after changing a tasklist is glitchy

Or was the designgoal totally different an I am missing something?

[mikro]

Hey Dan,

in my browser the images are ok.

I'll try to repost them here, see if it works.

[mikro]

[Fitnerd]

BUG: Weekly Planner View Crash

When you make a selection of time in the Weekly Planner view (without selecting any tasks) and begin typing on the keyboard (i.e. entering a task's title), that view crashes with NullRefernceException. What you have to currently do is first press Ctrl+N (or whatever shortcut is defined for the new task) and only then start typing. This is somewhat counter-intuitive for similar views in other programs.

[Fitnerd]

BUG: Copy-Paste from other Task List into Weekly Planner View

Actions:

1. Copy a task (as task) from Task List A
   
2. Switch to Task List B (either in the same or another instance of TDL)
   
3. Switch to Weekly Planner View on Task List B
   
4. Make a selection of the time slot, unoccupied by tasks (not a selection of existing tasks)
5. Paste the task

What Happens:

Task is pasted w/o proper start/end/due dates, and is not "constrained" to the selected time period.

Expected Behavior:

When pasting a task into a specific selection in the Weekly Planner View, the task being pasted (regardless of its time-related properties (start/end/due dates and time estimates) should be "fitted" within the selected time period (start/due/end dates set appropriately).

[Nico S]

Hi Dan,

as requested here my repost af the bug:

If i try to add/change some data via commandline, e.g. 

  todolist “C:\path\list.tdl” -tid 4 -s "done"

That doesn´t work. The task 4 is selected, but nothing is changed.

On the other hand, if I try e.g. 

  todolist “C:\path\list.tdl” -s "done"

The status of the currently (manually) selected task is changed correctly.

Same applies to other fields, like comments. (I did not checked all fields, yet)

So it seems to me, that the combination of -tid and an action doesn´t work in V. 7.2 rc10.

It does work with V7.1.5.0, however.

Thanks a lot:

Regards,

Nico

[mikro]

Bug: Print Layout 'File > Print ... ' Menu

Repost of my last issue here since I think it is a bug.

= = =

Hi Dan,

I tested a few variations and think that we are not viewing a corrupt file as I was thinking but a few formating problems.

What I did in succession.

If I create a new Tasklist with a custom Attribute and texts I get something equal to the introduction tasklist.

If I add folks to the 'Allocated To' when printed they are connected with a '+', linewraping only applies if there is a space in the name itself. If the whitespaces do not come in handy it looks like this.

If additional columns are added the comments column moves out of the sheets scope like this.

If a comment contains an expetionally Long string without whitespace (a link for example) the column width also exceeds the sheet

Now these cases are rather exceptions than the rule in a tasklist, but on a 30 page protocol they happen.

Since it is not possible to cover every possible input with a flawless print layout I would suggest to approach like so

• In the 'allocated to' layout:
  Replace the '+' inbetween allocated to members with a comma and a whitespace ',_'.
  The ',' saves some space an i.m.o. looks more "official". The ' ' gives additional linewrapping options.
  

• Force all columns to fit the assigened width no matter what.
  Like so the majority of tasks will be perfectly readable and a few ones may look akward.
  (If a few Long comments are allowed to enlarge the column over its limits all entries look akward. )

• If an entry exceeds the column width and normal linewraping does not work, I find it legitimate to the split and wrap the string where necessary to fit the page.

What I would find very helpfull also would be being able to

• arrange the column order
• modify min/max column width

Perhaps that way you could outsource a few formating issues to the user ;)

Hope the attachments work this time and the lineout of the issues helps.

cheers

Mikro

Am Sonntag, 21. Oktober 2018 03:32:29 UTC+2 schrieb .dan.g.:

[mikro]

Follow up: Task Tree expansion Bug

Hi Dan,

for information, on my PC I still can reproduce the Expansion bug with the Default Documentation.tdl

cheers

Mirko

Am Sonntag, 21. Oktober 2018 03:32:29 UTC+2 schrieb .dan.g.:

[mikro]

Bug: Custom Date Attribute Value if exported to .csv is '0.000000' instead of empty

Hi Dan,

exporting tasks with custom date attributes to .csv I have the issue that if no date is selected the exported value returns as '0.000000' formated as text.

I suggest that the exported value like with standard date attributes should be empty.

This would clean up exported csv tables und reduce manual work on agendas, protocols and alike.

cheers

Mikro 

Am Sonntag, 21. Oktober 2018 03:32:29 UTC+2 schrieb .dan.g.:

[.dan.g.]

Thx Nico, I'll have a fix for this in the next update.

[.dan.g.]

Thx Fitnerd, I'll get the crash fixed for the next update.

Regarding the issue of creating new tasks, my design ethos is only to ensure that all views work consistently with each other. Working consistently with other apps comes a distant second...

If you want me to consider this change, can you repost it with 'Suggestion: ' in the title.

[.dan.g.]

I know I usually want a bug report but this time unfortunately it's very hard to understand what is happening

Could you briefly describe the steps in words. Also what command is Ctrl+E mapped to?

[.dan.g.]

Hmm, that's not what I see...

Could you attach a modified version of 'Introduction.tdl' which shows this?

[.dan.g.]

Let me fix the wrapping of multi-values first and then see how things look...

ps. I will be using whatever Windows is set up with as the default list list item separator which is consistent with elsewhere in the app

On Monday, 29 October 2018 22:38:16 UTC+11, mikro wrote:

Bug: Print Layout 'File > Print ... ' Menu

Repost of my last issue here since I think it is a bug.

= = =

Hi Dan,

I tested a few variations and think that we are not viewing a corrupt file as I was thinking but a few formating problems.

What I did in succession.

If I create a new Tasklist with a custom Attribute and texts I get something equal to the introduction tasklist.

If I add folks to the 'Allocated To' when printed they are connected with a '+', linewraping only applies if there is a space in the name itself. If the whitespaces do not come in handy it looks like this.

If additional columns are added the comments column moves out of the sheets scope like this.

If a comment contains an expetionally Long string without whitespace (a link for example) the column width also exceeds the sheet

Now these cases are rather exceptions than the rule in a tasklist, but on a 30 page protocol they happen.

Since it is not possible to cover every possible input with a flawless print layout I would suggest to approach like so

• In the 'allocated to' layout:
  Replace the '+' inbetween allocated to members with a comma and a whitespace ',_'.
  The ',' saves some space an i.m.o. looks more "official". The ' ' gives additional linewrapping options.
  

• Force all columns to fit the assigened width no matter what.
  Like so the majority of tasks will be perfectly readable and a few ones may look akward.
  

• If a few Long comments can enlarge the column over its limits all entries look akward. 

[.dan.g.]

Hi Mikro

If we can agree that all filters are global ie. they are applied equally to whatever the active tasklist is, can you edit your post to remove the other possibility that you raised? Just so that I don't have to filter those comments out in my head (and get confused).

ie. Edit this post as if you already knew that filters are global when you wrote this post...

Then I'll delete this comment :)

Thx

On Thursday, 25 October 2018 19:38:23 UTC+11, mikro wrote:

Bug/Feature: 'Find Tasks' filtering rules vary inbetween different tasklists

Hi Dan,

thank you for another update!

I just stumbled about this issue that the same filter setup in the 'Find Tasks' window shows two different definitions for two seperate tasklists.

Btw. I use the same filterlogic for all my tasklists so filters are intended to be the same for each one of them.

Tasklist 1

Filter 'Turnus Intern Log'

Tasklist 2

Same Filter 'Turnus Intern log'

(after switching to another filter and back again)

 

I can image two intentions of yours

1. The filters should be the same for all tasklists => then we have a bug storing and loading the filter criteria

1. The filters should be individual for all tasklists => then clearing and loading the filters after changing a tasklist is glitchy

Or was the designgoal totally different an I am missing something?

[.dan.g.]

ps. I'll need your preferences too please (where the filters are stored)

On Thursday, 25 October 2018 19:38:23 UTC+11, mikro wrote:

Bug/Feature: 'Find Tasks' filtering rules vary inbetween different tasklists

Hi Dan,

thank you for another update!

I just stumbled about this issue that the same filter setup in the 'Find Tasks' window shows two different definitions for two seperate tasklists.

Btw. I use the same filterlogic for all my tasklists so filters are intended to be the same for each one of them.

Tasklist 1

Filter 'Turnus Intern Log'

Tasklist 2

Same Filter 'Turnus Intern log'

(after switching to another filter and back again)

 

I can image two intentions of yours

1. The filters should be the same for all tasklists => then we have a bug storing and loading the filter criteria

1. The filters should be individual for all tasklists => then clearing and loading the filters after changing a tasklist is glitchy

Or was the designgoal totally different an I am missing something?

[mikro]

Done ;)

[mikro]

Here you go.

[.dan.g.]

Great, thx.

First thing to note is that the Unique IDs for 'WiVo' are different between the two tasklists: cust_wivo vs cust_wiedervorlage.

And since both the tasklists and the preferences identify custom attributes by their Unique ID, this might account for the behaviour you are seeing. I will also verify for myself that this is the case.

What this means of course is that 'Find Task' searches cannot not be assumed to be entirely 'global' if they utilise custom attributes.

If you want the 'WiVo' attributes to be equivalent you will need to:

1. Load the tasklist requiring 'fixing' into a text editor (eg Notepad++)

2. Find/Replace the Unique ID to match the other tasklist (match 'whole word' and 'case sensitive', and possibly replace one instance at a time)

3. Load your preferences file into a text editor

4. Find/Replace the Unique ID as 2.

Dan

[mikro]

Ok, thanks for the update.

I'll look into it and get back to you.

[Fitnerd]

As requested, reposting focus-loss during autosave bug here:

This is likely a bug, unless it's by design. The problem is that when I am in the middle of typing a longish item into one of the drop-down fields (like Category for example), TDL would auto-save my task list, and that causes the active control (i.e. combobox) to lose focus, which I don;t immediately notice and continue typing.

This leads to entry corruption: instead of having for example "some long entry", it would have "some long" -> [focus lost/regained] -> "entry", or "some long" -> [focus lost/regained] -> "entrysome long" (depending on when the focus is regained and where cursor is positioned). Usually instead of a single entry it would produce 2 partial entries, or sometimes just one but with the wrong order of words. So, you then have to drop-down the list, delete the corrupt entry, and type it again in time.

Thank you.

[Brendan T]

Hi Dan,

if I link tasks together in the Gantt view the weekend days are not accounted for.  So, if Task B is dependent on Task A and Task A finishes on Friday, then Task B is starting on Saturday.  Unless I have missed a setting for this.

Brendan 

[mikro]

Hey Dan,

sorry, forgot to line that out.

Step by step

• I expand the tasklist fully with  'Expand all tasks' (mapped to Ctrl + E)
• collapse a subtree via mouseclick
• then try to reexpand all via Ctrl + E, which doesn't work.
• then I collapse all via 'Collapse all tasks' (mapped to Ctrl + R) which works
• after which I can Expand all with Ctrl + E again

So after expanding all once an then manipulating the tree via mouse the 'expand all' doesn't seem to work until the whole tree was collapsed once.

cheers

Mikro

[mikro]

Many thanks,

Filters now behave 'alike'.

cheers

Mikro

Am Mittwoch, 31. Oktober 2018 03:37:11 UTC+1 schrieb .dan.g.:

[mikro]

Sounds good to me!

thx!

[.dan.g.]

Hi Brendan

You need to make sure that the 'Time Estimate' units are 'Weekdays'.

[.dan.g.]

ps. You can set up 'Weekdays' as the default 'Time Estimate' units in the 'Preferences'

On Sunday, 4 November 2018 22:38:23 UTC+11, Brendan T wrote:

[.dan.g.]

Thx Fitnerd, I'll look into it.

[Robin]

Hello, this is the Rendering issue again

I recently switched from an old 6.8 version to the current 7.2 release candidate.

Seems like a lot has been improved, there is also a new task tree view.

Here I can see some flickering when opening/closing task hierarchies. 

And when scrolling down using the mouse wheel you can see rendering artifacts.

The scrolling routine when using the slider works a bit different though so you need to scroll very fast to see the issue.

I think this is because the renewed task tree view has no double buffering or something to hide the rendering till it's finished.

I've also testet V7.1.5 which has the same issue.

The old V6.8 has no rendering issues.

I'm using Window 7 64bit and tested in on 2 different computers which I use everyday.

 

Thanks,

Robin

PS: Here is a screenshot taken from a screen video capture to make it clearly visible.

[G-Eric]

 Hi Dan,

I noticed that a custom created field of type 'icon' can't be cleared anymore in the lower 'Edit' zone.

In the attached 'Introduction.TDL' file, I created a new custom filed 'MyCustom' displayed in column 'MyIcon'.
This field is of type 'icon' with a fixed list of one single icon.

When you click on the column cell, it toggles the icon as expected (displayed vs cleared) = ok.
When you go to the lower 'Edit' zone, you can activate the field contents (i.e. the icon is displayed) but there is no way to clear the filed value - a value 'empty' (as first line of the proposed drop-list) is missing.

In the past, it was working fine to manage the value into le lower 'Edit' zone, i.e. no need to have the column on screen.
In this version, the only way to clear the field is to have the column on screen to toggle the value by clicking on it.

Thanks for your work - Eric

[.dan.g.]

Thx Eric, I'll get this fixed for tomorrow's update.

[G-Eric]

I thank you Dan - It will help for managing custom fields.

[G-Eric]

Hi Dan,

I noticed a bug for the display of due time - minutes are not in "synced" between table cell and lower zone 'Edit'

You will find attached the 'introduction.tdl' where I created a new task 'MyDue_MinutesNOK'.
I also attached a print screen to document the issue.

When you change the due time back and forward a few times (e.g. 11:30 > 14:00 > 11:30 > 3:00 > 11:30), it ends by having a difference between the table cell time minutes and the lower zone 'Edit' time minutes.
So far, I only noticed one minute of differences during the tests I did, which is not a lot but sufficient to miss a selection from a filter - therefore I report it.

When reopening the file, it displays 11:29 everywhere (cell + edit) despite my selection of 11:30 in the drop list.
Therefore my feeling is that there is a hidden computed value rounding issue.

Thanks for your work - Eric

[.dan.g.]

Thx Eric, but I can't yet reproduce the issue so it might have to wait until after RC11

[Eric Gilon]

I did more tests and noticed it only happening with a time span of several days between start date and due date (i.e. Fri 09 Nov and Mon 12 in my sample). I can find so far neither the reason of the link nor the limit to trigger, but I reported it in case it might ring a bell somewhere.

Thanks for your effort - Eric

--
Download Latest Version: http://abstractspoon.pbworks.com/f/todolist_exe.zip
Website: http://abstractspoon.weebly.com/
Wiki and other resources: http://abstractspoon.com/wiki/doku.php?id=todolist-description
---
You received this message because you are subscribed to the Google Groups "ToDoList (AbstractSpoon) Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to abstractspoon-todolis...@googlegroups.com.
To post to this group, send email to abstractspoon-t...@googlegroups.com.
Visit this group at https://groups.google.com/group/abstractspoon-todolist-support.
To view this discussion on the web, visit https://groups.google.com/d/msgid/abstractspoon-todolist-support/87a943eb-dc00-42c5-bb68-6761e20eb0e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brendan T]

yip, that's it.

thanks Dan

[.dan.g.]

Crash fixed in 7.2.RC11

On Friday, 26 October 2018 22:00:50 UTC+11, Fitnerd wrote:

BUG: Weekly Planner View Crash

When you make a selection of time in the Weekly Planner view (without selecting any tasks) and begin typing on the keyboard (i.e. entering a task's title), that view crashes with NullRefernceException. What you have to currently do is first press Ctrl+N (or whatever shortcut is defined for the new task) and only then start typing. This is somewhat counter-intuitive for similar views in other programs.

[.dan.g.]

Fixed in 7.2.RC11

On Monday, 29 October 2018 18:45:55 UTC+11, Nico S wrote:

Hi Dan,

as requested here my repost af the bug:

If i try to add/change some data via commandline, e.g. 

  todolist “C:\path\list.tdl” -tid 4 -s "done"

That doesn´t work. The task 4 is selected, but nothing is changed.

On the other hand, if I try e.g. 

  todolist “C:\path\list.tdl” -s "done"

The status of the currently (manually) selected task is changed correctly.

Same applies to other fields, like comments. (I did not checked all fields, yet)

So it seems to me, that the combination of -tid and an action doesn´t work in V. 7.2 rc10.

It does work with V7.1.5.0, however.

Thanks a lot:

Regards,

Nico

[.dan.g.]

Wrapping issue fixed in 7.2.RC11

[.dan.g.]

Fixed in 7.2.RC11

On Tuesday, 30 October 2018 00:20:29 UTC+11, mikro wrote:

Follow up: Task Tree expansion Bug

Hi Dan,

for information, on my PC I still can reproduce the Expansion bug with the Default Documentation.tdl

cheers

Mirko

Am Sonntag, 21. Oktober 2018 03:32:29 UTC+2 schrieb .dan.g.:

[.dan.g.]

Fixed in 7.2.RC11

On Sunday, 4 November 2018 01:12:52 UTC+11, Fitnerd wrote:

[.dan.g.]

Fixed in 7.2.RC11

On Friday, 9 November 2018 03:13:28 UTC+11, G-Eric wrote:

[G-Eric]

Tested and found ok in v7.2.RC11 - Thanks for the fix

[.dan.g.]

Thx, I can reproduce it now.

To unsubscribe from this group and stop receiving emails from it, send an email to abstractspoon-todolist-support+unsubscribe@googlegroups.com.
To post to this group, send email to abstractspoon-todolist-sup...@googlegroups.com.