Family Historian User Group

First let me say that many of the improvements in V3 are wonderful... I'm still exploring the possibilities.

But I was a little disapointed that the bugs in the properties dialogue haven't been addressed. If you (for example) add a second source to an individual, type something in 'Where within...' and then hit the up button to put the citations in some preferable order, it loses your input. There are lots of other examples of this sort of behaviour in this dialogue, so thet I've got into the habit of hitting F5 everytime I enter something to be on the safe side, but I still forget sometimes and loose stuff (and why F5?... wouldn't you expect the Enter key to do that, it's much easier to find without looking down, and has no other meaning here).

(Still a fan though)
Chris

ID:1609

You should find the Tab key will 'save' the data on any field.

Sorry, I realised I'd posted this in the wrong place... yes, Tab does it too but not always what you want. The main point is it shouldn't just loose what you typed if you don't explicitly save it.

Chris - thank you for pointing this out. We weren't aware of it. You say that there are lots of other examples. I found on experimentation that I could get what you describe to happen by pressing the up or down arrows in the source pane, just after entering data in any source pane field (i.e. without pressing Tab). But I couldn't find any other examples. Do you know of any that can happen in any other way?

Simon, I'm sorry, I've only just noticed your reply... I'd be happy to do an exhaustive investigation... not sure it's appropriate to post it all here though. If you email me I'll send you what I find. Since I discoverd the problem I've trained myself to hit F5 all the time, so I'll need to do a bit of work on it.

On the subject of losing data: If a property dialogue is brought up, say by double clicking on the name in the individual record, the person's name in the property dialogue is highlighted. If at that point you inadvertently press the space bar the name is deleted and you may not notice. This also happens to any other field in the property dialogue if it is highlighted and the space bar pressed.
Perhaps this is something Simon could look at please.
thanks Peter E

This is normal behaviour in dialogues in Windows. I'm sure it would be a mistake for FH to do anything different.

I agree with Peter on this. I have been conscious for some time of the potential for losing data through the possibility, say, of a document you are perusing on the desk impacting the space bar and wiping the highlighted field. It might be standard Windows behaviour but I would prefer a diferent behaviour where my data is kept more secure.

Firstly I don't see why the space-bar is being singled out, pressing any key that produces a letter/number/symbol will cause the name to be deleted. I agree that this does seem a little dangerous, especially with the lack of an undo feature.

The only reason why some dialogues in Windows highlight the first text box when the dialogue opens is for convenience, I can't think in these circumstances of why it would be convenient, perhaps just highlighting the text-box if the individual doesn't have a name entered would be better.

You can undo in text boxes... Ctrl+Z or right click and select Undo

True (and well worth reminding people of) but not if you've then moved off onto another text box, it doesn't retain an undo history. Also most applications which do this would have a cancel button on the dialogue (though I can see why this wouldn't be a good idea in this case). The point is why does the name need to be highlighted at all? The reason for doing this is for fields where you are likely to want to type in entirely new data but it is very rare that you will want to change the name of someone or indeed alter any field that already has data in. The cursor could simply be placed at the end of the textbox, no need to highlight it.

ChrisBowyer said on 24/09/06 'This is normal behaviour in dialogues in Windows. I'm sure it would be a mistake for FH to do anything different.' with regards to the highlighting of the name field when the property dialog is initialy displayed.

I would agree that it's normal behaviour for many Windows programs, however there are exceptions to the rule when such an action gets in the way.

In fact FH doesn't highlight the name field under certain circumstances. If you double click an individual in the record (or query) window for the first time their name isn't highlighted. However if you then double-click them again the name is highlighted. Inconsistent behaviour. If you then double-click someone else their name isn't highlighted. I would argue that not highlighting the name field is the right thing to do especially if there is a name already there. It would be a very rare occasion that you select an individual to totaly re-write their name.

Another issue with highlighting is when you have parameters in a query. When you run the query and the dialog appears to enter the parameters the first (or only) field is not automatically highlighted. In fact it's a bind that it isn't since the whole point of parameters is regularly changing them so the most likely action is to change the parameter - which the current method requires you to select the text and overwrite.

Sorry to raise this old issue, just catching up with issues as I read the forums.

Further to my last message, I take it back. FH does always select the whole name field when you double click a record.

However FH did for some time, till I closed it down and restarted it, not highlight the name field unless I took the actions described in my previous message. Something, I don't know what, changed FH's behaviour. A clue to the bug is that when FH was not highlighting the name, the property dialog would NOT be updated with the current individual as it normally does if you just click once on a person.