Peculiar auto text behaviour.

johnmorrisoniom · Post by **johnmorrisoniom** » 01 Dec 2011 15:34

It's taken me a while to track down what's been happening.
Two computers, one running XP 32 bit and AS2 32 bit. The other is on W7 64bit and AS2 64 bit.
Win XP machine: census entry.
Enter census details and click auto text.
Edit atuto created text to match actual census.
Regardless of whether the auto option at bottom of page is ticked or unticked, clicking save, saves the modified version of the text.
W7 machine all ok same as above until save. If the auto option at the bottom of the page is unticked, the modified text is saved. If the box is ticked, a new auto is performed reverting your text back to pre-modified text and then saving.
One of these is not doing what it's supposed to, but which one?

ID:5606

Post by **NickWalker** » 01 Dec 2011 20:36

Not sure if I've totally understood what you're saying and I've not had chance to test this in any detail but what I believe to be the case is written below and this works exactly the same in Win 7 and XP.

If the box is ticked and you haven't typed anything into the source text box then auto-text will be performed, (including just before saving).

If the box is ticked and you have typed something into the source text box then the auto-text will not be performed again.

If the box is unticked and remains unticked then auto-text will not be performed again

If the box is unticked and then later ticked again auto-text will only be performed again if the text box hasn't had any extra text entered.

If you click on the Auto button having previously typed something into the text box then you will receive a warning. If you opt to allow the auto-text to be performed then it will be as if it has never been typed into and so will continue to be auto updated if ticked.

Nick

johnmorrisoniom · Post by **johnmorrisoniom** » 01 Dec 2011 21:00

Hi Nick.
That is what I thought was supposed to happen.
Only with win 7 x64 and AS2 x64 even after you have typed in the box the text gets auto done again on save, with no warnings

Post by **NickWalker** » 01 Dec 2011 22:43

I use Win 7 x64 and I don't see that happening and looking at the programming code, as soon as you press a key in the text box it triggers the auto-save not to happen.

So are you saying that if you press Auto button, untick the auto checkbox, type in some additional text into the source text and then save, then the text you typed in isn't being saved?

Actually I can see this could happen if you pasted some text in rather than typed it. Is it possible that is what you are doing?

johnmorrisoniom · Post by **johnmorrisoniom** » 02 Dec 2011 09:24

I always use the auto button to generate the text.
When I modify the text and untick the auto option at the bottom, the modified text is saved.
If I leave the auto option ticked (which is the default) the text reverts to the originally created auto text and saves with no warning.
It happens very quickly, and I only noticed because I had abbreviated a lot of middle names to initials.
It isn't very obvious, and you would need to check the saved file to see what happened.
This doesn't happen on the 32bit version on Win XP.

Post by **tatewise** » 02 Dec 2011 10:44

For what its worth I cannot reproduce John's problem either on Windows 7 x64 and AS V2 x64.
Does the problem occur on all Census years?
Are you using the Default Auto-text template?
Do you edit directly in the Auto-text box or use the Text link to edit in a popup window?
Does it happen on various Census grid entries?

Post by **NickWalker** » 02 Dec 2011 10:47

Yes I did check whether it was changed or not in Family Historian and it worked as expected.

Is anyone else seeing the problem that John is seeing? Please could one or two of the experienced AS users try the following (with a test project/file):

1) Choose a census
2) Add an individual to the census
3) Press the Auto button.
4) Make sure the Auto tickbox remains ticked
5) Type in some extra text into the Source text box.
6) Save the entry.

If it is working correctly then if you look at the file in Family Historian it should include the extra text you added to the source.

[EDIT: I see that Mike has done this, so thanks for that]

johnmorrisoniom · Post by **johnmorrisoniom** » 02 Dec 2011 12:20

I am using default everything, although I have vreated my own 19101 and 1911 Isle of Man versions, these are just copied from the UK version with an added language field.

I am using method 2

This behaviour has just also happened on my win XP machine.

Is it just that I should always untick the auto option if I modify the text?

I usually modify the text in the main window, and only occasionally use the optional pop up window

Post by **tatewise** » 02 Dec 2011 12:42

It appears to be the Method 2 mode that has the problem.
The shared Note created after Save did not contain the Auto-text edits, it had reverted to original default Auto-text.
If the Census settings - method 2 option for Source Text is changed to In local citation text then the FH citation Text From Source doe not contain the edits.

Post by **NickWalker** » 02 Dec 2011 20:12

I'm still not seeing this error at all. Can you give me a set of steps to replicate it?

With census method 2 selected (doesn't matter in my tests if local or shared note) I select a census year, add someone to the census grid. Press the Auto button, type some extra text into the source text and then press Save. I ignore the warnings about no image, no reference, etc. When I load up the file in Family Historian the extra text I added is there.

Post by **tatewise** » 03 Dec 2011 10:43

On further experimentation it is not a Method 2 problem - it applies to Method 1 as well.
The problem arises only if text is deleted from the Auto-text box and no text is added.

There are a couple of ways to confirm this problem:
1) Create Auto-text by pressing Auto button, delete some text from Auto-text box, then press Auto button again, and it does not warn that the text has been changed.
2) Create Auto-text by pressing Auto button, delete some text from Auto-text box, delete Age entries from Census Grid, click Save File and when warning about Not all the ages are filled in pops up the Auto-text reverts to Default values.

In any case if Ages are filled in when Save File is clicked and all warnings accepted then Auto-text flashes to Default values and saved to Gedcom.

johnmorrisoniom · Post by **johnmorrisoniom** » 03 Dec 2011 10:46

From Memory, I think Extra text is retained, it is things like names and birth places, that, when edited to reflect what is in the census, they revert to what is in the gedcom file.
So if names have been shortened to initials and place names shortened, that's when it happens.
I will try and generate a few screen captures over the weekend for you

johnmorrisoniom · Post by **johnmorrisoniom** » 03 Dec 2011 13:01

I have succeeded in replicating the behaviour.

If the text is only deleted then it reverts on save.
If text is also added, then all the changed are kept.

I have done a set of screen captures to demonstrate, but all I did was:

A: entered 2 or three people (I chose family historian demo file and used as head Charles William Munro, because he has two forenames and no DOB, plus wife and son)

B: Added fictitious age , occupation and place of birth

C: press auto to generate text

D: Edited said text to change middle names to initial and place of Birth for son to just USA

E: Click save, Box pops up to accept birth date/place, in background text has reverted to initial autotext.

F: Click Cancel & re-edit text.

G: added an extra line of text after autotext.

H: Click save, Box pops up as before, but edited text has stayed edited.

I did this on my win XP machine using method 2

Hope this helps track it down

Post by **NickWalker** » 03 Dec 2011 16:58

Yes this makes sense. I am detecting if the text box has been manually edited by detecting a key press within. But this doesn't detect deleted text or indeed pasted text. I suspect that 99% of the time an edit will involve adding text, even if just putting in extra space, which is why it hasn't been spotted before.

Thanks for helping me to track the problem down and I'll aim to fix it in the next version.

Best wishes

Nick

Family Historian User Group