* Slight Annoyance when miss-entering places/addresses

[ChrisRead]

I've been meaning to remember to mention this for a while. This issue occurs on places, addresses and occupations at the very least.

On a number of occasions, I've accidentally entered something with the wrong case (usually I've got a letter wrong). Once it's been entered, AS helpfully remembers what you entered so, it can predict what you're entering if you start entering it again (very useful feature). However if you re-enter it with the intended case to try and correct it, it will revert it to what AS first remembered. This includes trying to re-enter the original and sometimes only instance of the text. There seems to be no way to get round this as far as I've tried, without starting over or entering it slightly differently.

I hope the explanation makes sense. It's easy to try it out.

[tatewise]

I suspect AS uses the same technique as FH to suggest Place, Address, Occupation, etc, values.
The values are drawn from the existing values in your Project data as opposed to an independent list.
So have you tried using the FH Tools > Work with Data options to correct your FH data?

[NickWalker]

On a number of occasions, I've accidentally entered something with the wrong case (usually I've got a letter wrong). Once it's been entered, AS helpfully remembers what you entered so, it can predict what you're entering if you start entering it again (very useful feature). However if you re-enter it with the intended case to try and correct it, it will revert it to what AS first remembered. This includes trying to re-enter the original and sometimes only instance of the text. There seems to be no way to get round this as far as I've tried, without starting over or entering it slightly differently.

Yes I can see what you mean and it is annoying. I'll have a think about the best solution to that.

I suspect AS uses the same technique as FH to suggest Place, Address, Occupation, etc, values.
The values are drawn from the existing values in your Project data as opposed to an independent list.
So have you tried using the FH Tools > Work with Data options to correct your FH data?

AS also includes any places, etc. you're typing into the current entry e.g. if you enter a new place into the Baptism place that place will also autocomplete in the residence fields. That causes the problem Chris is describing.

[David2416]

Thanks for raising this Chris. I sometimes enter something like "ENgland" - it would be good if AS could unremember it!

[tatewise]

AS also includes any places, etc. you're typing into the current entry e.g. if you enter a new place into the Baptism place that place will also autocomplete in the residence fields. That causes the problem Chris is describing.

Chris also mentions Addresses, Occupations, and other values. If they are new values does AS remember them locally too?

It is not clear from what Chris says whether the problem he describes only exists within one AS session or persists from AS session to AS session. I suspect the latter is resolved by the Tools > Work with Data techniques I suggested, because I believe that AS does not remember such values from session to session.

[David2416]

AS also includes any places, etc. you're typing into the current entry e.g. if you enter a new place into the Baptism place that place will also autocomplete in the residence fields. That causes the problem Chris is describing.

Chris also mentions Addresses, Occupations, and other values. If they are new values does AS remember them locally too?

It is not clear from what Chris says whether the problem he describes only exists within one AS session or persists from AS session to AS session. I suspect the latter is resolved by the Tools > Work with Data techniques I suggested, because I believe that AS does not remember such values from session to session.

I don't disagree with that. The problem is during an AS session.

[NickWalker]

I'm not seeing this issue with Addresses or Occupations - just Places. Addresses and Occupations are both drop-down lists and the auto-complete on them just uses the standard built in method (no coding involved). I can't find any occasions when it won't let me enter text in the correct case - it may suggest the wrong capitalisation if an incorrect entry had been made previously, but it allows me to correct it in the new entry. This isn't the case with Places.

The Places text box uses my own algorithm for suggesting the most appropriate matching place. As has been pointed out, AS in the current version (and all previous versions) is extremely case sensitive when entering places. For example, if I wated to enter the place name as Usk, as soon as I type the U it suggests USA, if I then type in the 's' it will still suggest USA and now capitalises the S. If type k it will then accept that, stop suggesting and I end up with uSk and I now have to go back and make the S into lower case.

I've now fixed this in my development version so this should work correctly in the next release.

[ChrisRead]

It's definitely on Occupations as this was what reminded me to report on it. IIRC I entered something like "Innkeeper's SOn" and hit enter to go to next entry (was doing a census). When I went back and re-typed as "Innkeeper's Son" (ignoring the offered auto-complete) and enter, it would revert to "Innkeeper's SOn". That was what was also offered in the drop-down list. I almost never use the drop-down list entries directly anyway as auto-complete as a I type most times seems quicker in the workflow. It seems that the predictive algorithm is case insensitive so does not recognise that the remembered value is actually different to what was just typed, and therefore thinks the remembered one is the same and uses it by preference.

I've come across some implementations, where if you have a non-fixed drop-down list (meaning things get added by the app), you can highlight an entry (using cursor keys) and then hit the delete key to remove the entry from the list. I think this was on something like remembered previous filenames or something similar. Can be useful at times. It could work in this case to remove a bum entry from the list caused by a case error as I was doing. There are a few subtleties, such as what if you delete one that is in use, but hey, that's software dev for you.

[NickWalker]

Thanks Chris. You're right there is an issue with combo-box controls within the data grid. This is a fault with the underlying Microsoft control in that it isn't case sensitive in the way it handles auto-completion. So I've now replaced the built in system with my own in my development version. It will allow you to correct the text and if the text already exists (ignoring case) it will replace it in the list. So if you added "Innkeeper's SOn" and then typed in "Innkeeper's Son" it will replace the original version in the list. This seems to resolve the problem as far as I can see when testing it. But when I eventually release this for testing, perhaps you would be kind enough to check.

Cheers

Nick

[ChrisRead]

Ok, thanks, I await it's appearance. I suspect that your approach (replacing the case insensitive entry) is actually the desired behaviour in almost every circumstance in which it occurs. I can't think of a reason you'd want the same text with letters in a different case except some sort of pedantry regarding how something was written inconsistently in a source. That would mean allowing multiple versions with different case to be in the list, and you'd have to pick the one you want in the list because the auto-predict would probably struggle to give you the one you want without potentially typing most of the word(s) anyway.