* Record window anomaly

[johnhanson]

With a large database for a one-name study which covers the whole world - 41k+ people I have a number of queries that I use be able to sort out things like missing census in say USA as opposed to UK

Within a query you can set the sort order of any column to Ascending, Descending or None

However if I use that query to reset the column headings in the records window (if I am working on a batch in the USA is easier than keep running the query) the sort on the records window only has two settings - ascend or descend and all are set to ascend by default in the "Configure columns screen"

Surely with all of the columns set to ascending it is a conflict?

Why can't we have just on column as a sort setting like the Query

[jelv]

Having a sort on all columns isn't a conflict as they all could affect the sorting of the records - even the last column if all of the other columns being displayed are equal on some records.

[tatewise]

The column sort rules for the Records Window and Query Result Sets are not defined anywhere in the Help.
Furthermore, they are not consistent with each other.

In the Records Window, the rows can be sorted primarily on any column by clicking its header.
If that column has identical row values the row subsets are sorted according to the lefthand column.
If that column has identical row values in each subset then those rows are sorted by the next column and so on.
In other words, the rows are sorted on a primary column and then sorted in groups from left to right columns.

In the Result Sets, the rows can be similarly sorted primarily on any column by clicking its header.
However, if that column has identical row values the row subsets are sorted randomly even if the other columns have a defined Sort order.

Plugins that create a Result Set can not only specify each column sort order but also the column sort precedence, so the sort rules are fully defined. In theory, it should be possible for Query Result Sets to offer the same feature.
FYI: Other Result Set features, that were first added to Plugins, later migrated to Query Result Sets.

[LornaCraig]

In the Records Window, ..... the rows are sorted on a primary column and then sorted in groups from left to right columns.

It has always been my understanding that in the Records window the last three sorts are ‘remembered’, so that if a column has identical row values the row subsets are sorted according to the last used sort order and so on. This is not the same as sorting the subset by left to right order of columns. Unfortunately I can no longer find this documented, and I'm not sure if it is still the case. (Don't have time to experiment fully at the moment!)

[NickWalker]

Slightly off-topic (but only a little), I've always been frustrated that clicking on a column that is sorted in ascending order doesn't then flip it to be descending like it does in most applications I use. I can never remember which of the control keys I need to hold down when clicking so end up trying Alt or CTRL or Shift before I find which one it is. The method Lorna describes is quite common in other applications such as an Excel filter row so if you wanted to see a list of people sorted by place of birth then their name you would click on the Name column to sort that, then the place of birth column to sort that. The places would then be in order but within each grouping they'd be sorted by name.

[tatewise]

Yes Lorna, you may be correct. I'd forgotten about that wrinkle!

That is another difference compared with Query Result Sets which have no such memory.

This is another unfortunate example of inconsistencies in related functions in FH.

[Mark1834]

I think Lorna's interpretation is correct. In fact, that is the method usually advised here for sorting on multiple columns - sort in order, least significant first, and the previous sequence is maintained.

Tested by sorting on birth place, which is in the middle of my records window, then by death place, which is over on the right. The display is then sorted by death followed by birth, and columns to the left of birth are ignored.

Wanting a fully-defined Query sort feels like a Wish List item, but it might be a challenge for CP to implement it in a straight-forward way without creating inconsistencies between Records Window, Plugins and Queries.

Plugins can fully define the initial sort, but I don't think subsequent sorts of the displayed results support sorting on a secondary column. If I click on an unsorted field, records with identical values for that field appear to be displayed randomly, not sorted by the previous sort order.

[tatewise]

I would expect a Wish List item to request that sorting of all multiple row & column lists be fully consistent.
Then all Records Window tabs, Query & Plugin Result Sets, Named Lists, etc, would all behave similarly.
How CP achieve that is their challenge.

[AdrianBruce]

I think Lorna's interpretation is correct. In fact, that is the method usually advised here for sorting on multiple columns - sort in order, least significant first, and the previous sequence is maintained. ...

Agreed. On my Individuals tab, if I mess up the tab's sort order by clicking on the Spouse or Father column and then click on the Name column, the names are in order, but the order of (say) the Elizabeths with no surname is undefined.

On the other hand, if I mess up the tab's sort order by clicking on the Spouse or Father column and then click on the Dates column, followed by the Name column, the names are in order, and within each name, they are in date order. (Names with no dates look a bit odd - I suspect there may be a previous-previous sort order confusing the software. Or confusing me.)

[Mark1834]

The challenge in drafting a new Wish List item will be to recognise that output from either plugins or FH menu options can never be completely consistent with Query or Record Window displays, as the latter are fully dynamic and reflect changes in the underlying data, while the former are largely static. As a result, you could be sorting on obsolete data, which I’m not sure is logical.

However, I agree that more commonality in how the displays sort (both with each other and with other common apps) would be beneficial.

[tatewise]

... Query or Record Window displays, as the latter are fully dynamic and reflect changes in the underlying data, while the former are largely static. As a result, you could be sorting on obsolete data, which I’m not sure is logical.

In my experience Query/Plugin Result Sets do reflect underlying data changes just like the Records Window.
Nevertheless, even if the data was 'slightly' obsolete, having consistent sorting would still be useful.

[Gowermick]

A point to note, is that the sort order of Source Records displayed in the records window, defines how they are presented when choosing a new or existing source.
For example, I normally sort sources by name, using the underscore character as a prefix, to force my more commonly used ones to the top of the list. Occasionly I need them in reverse creation date order, so that the most recent ones are at the top. I just amend the sort order in the records window, and FH remembers this order, next time I want to add a new/existing source.

[Mark1834]

Columns displayed as item data (Records) update dynamically, but text and numerical data don’t. It creates a limitation in using either plugins or built-in menu options to tabulate detailed data (such as source citations) to check for consistency or omissions, as the display has to be regenerated when data are changed.

[tatewise]

... the sort order of Source Records displayed in the records window, defines how they are presented when choosing a new or existing source.

Typically that applies to any record type when presented in a select record dialogue but the order can be overridden by sorting on any column in the select record dialogue.

[jelv]

For example, I normally sort sources by name, using the underscore character as a prefix, to force my more commonly used ones to the top of the list.

That's not the best way to do that!

Add the commonly used ones to the named list Bookmarks. You can do that by right clicking the sources in the Select source popup.

Now, when selecting a source, at the top left click the middle icon and it shows you just the bookmarked sources.

Bookmarked sources.png (4.71 KiB) Viewed 364 times

[Gowermick]

John,
That’s an extra mouse click
I only have 6 or 7 priority sources, if I want another source like censuses, I use the filter box at the top, and a shortcut keys to search for specific census entries. This is particularly useful, so I can check if I already have already used the specific census page reference, to save me duplicating it.

[johnhanson]

Mike
Apologises for delay been a crazy weekend
Yep appreciate the difference between query and records window
It was more to do with the fact that the query has a null sort option and the records window doesn't
When you only have the default set of columns is less of an issue and I suppose if you use the focus window then it is not an issue anyway
But I never use the focus window - wasn't there when I started and with multiple trees in the one database is a pain anyway

However, you said
"In the Records Window, the rows can be sorted primarily on any column by clicking its header.
If that column has identical row values the row subsets are sorted according to the lefthand column.
If that column has identical row values in each subset then those rows are sorted by the next column and so on.
In other words, the rows are sorted on a primary column and then sorted in groups from left to right columns."

Therein in lies the problem with the records windows - because the sort is from left to right
When I re-open FH I want it to sort automatically into the last updated column so unless I make that the first column - which seems illogical to me - I am always going to have to do mouse clicks to get where I want
Why can't the record window have a null sort like the query window

[tatewise]

John, I think you have overlooked Lorna's correction to my posting and some of the later discussions.

1. You can override the left-right sort precedence by clicking column headings in reverse of desired sort order.
   However, those sort precedence rules only apply when you change the primary sort column.
2. FH remembers your sort preference indefinitely. So if you sort any Records Window tab by the Updated column then whenever FH is reopened the records will still be sorted in Updated order. The sort preference is remembered independently for each tab.