1 - When using the very useful Date Calculator, you commonly start by entering the End Date.
But to enter the Age, I would like to use ‘‘Tab’’. Unfortunately ‘‘Tab’’ doesn’t move the cursor anywhere
You must on Age to enter it, then the Calculator calculates the Start Date and proposes to insert it in the corresponding field. Because these calculated dates are very often estimated ones, would it be possible to add under the field ‘‘Start Date’’ a free text box that we could fill with the text we want to automatically add? And why not 2 text boxes, one for text before the calculated date, and another one for the text after.
2 - When in any list, when clicking somewhere in the vertical slider, that the list scrolls automatically up or down for 2 thirds of its current size, like as everywhere in Windows or other windowed interfaces. For now, it’s one item by one, but top and down arrows exist for doing this.
I had a third one, regarding Search in Lists, but it’s corrected in this last release. Fantastic
EVERY slider bar has numbers to the left that indicate the current value of that slider. They can be changed directly, instead of moving the slider. Mouse-click them or Tab to them.
Well I must be confused or we are talking about two different things. I was hoping that you said I could adjust (hopefully permanently) the scroll slider in things like Place List (see attached screenshot). Now I find the arrow box moves one line and clicking in the scroll bar also only moves one line. I would like to adjust the second action to move about 20 lines (more or less a screen at a time).
Sorry, two different things. Those sliders require either pressing mouse pointer down (within the narrow channel below or above the slider button) and keeping it pressed to move down/upward at a scrolling clip -or- highlight a place name and then use the up/down arrows for same scrolling movement.
I agree with @fahumm , what you describe is not how the list ought to scroll: it must scroll about 2 third of the shown lines when you click in the slider itself, above or below the slider button. And not only one line by one line, the top and bottom arrows are here for one by one line moves.
Pretty sure too, if nobody took time doing the remark. But it’s disturbing when you are working day long on windowed interfaces then switch to RootsMagic.
The box/index combination has two flavours. Flavour 1 dynamically filters the records according to what you have input, matching surnames against input before a comma and first names on what you input after a comma. This works on
The index to the people screens
The people list
The couples list (filtering on either husband or wife)
Flavour 2 brings into focus the first record in which the surname starts with the characters that you have entered. It will move part of the index/table so that this record is visible. If it finds this record by scanning downwards, then the record will be at the bottom of the visible part of the window. This works on
The Roots Magic Explorer (used for marking freeform groups, selecting people to colour code, include in a Gedcom or a report etc)
Treeshare
The interface with FamilySearch.
There may be others that I have forgotten about.
It seems like a very deliberate decision by the developers to have two separate versions of this, and I suspect that they have good technical reasons for doing so.
In principle, I would prefer flavour 2 to move the highlighted record to the top of the window, but this is not even my top priority for improving the operation of this tool in treeshare; much more important for me is the fact that RM9 completely refreshes the window when you select or deselect ‘only show changed people’ and moves the focus to the top. (RM 7 retained the focus on the same person.) This makes the already laborious treeshare process worse than it would otherwise be, because I have to continually note the name of the person I am working on, unclick the ‘changed people box’ and then key the person’s name in.
I have found this annoying for years, especially with a long list, but never bothered to report it. It’s not how native apps work on either Mac or Windows, which I think is what @fahumm and @ClipOn are asking for.
