Canceling input for Source not working as expected

[Matjaz]

I'm noticing the following behavior in the Aries editor:

When creating a source (i.e. Add source followed by Edit source) for an Individual or a Family, it is not always possible to cancel the input as one would expect. By clicking Cancel, the result is often the same as if one clicked OK. I'm noticing a similar behavior also when adding a new multimedia object in Gallery. Please, see my workflow in the attachment for more details. THIS BEHAVIOR DOESN'T HAPPEN EVERY TIME, BUT I CAN'T FIGURE IT OUT WHY AND IN EXACTLY WHAT CIRCONSTANCES!

I've learned to be careful to immediately delete such unwanted entry in the next step. In the Entities table, the entry for the entity can be either kept and processed for another source/multimedia object or deleted. However, it may happen that the source or multimedia object will be used with the wrong Idividual or Family or several of them if the whole thing is overlooked. Unfortunately, it still happens to me quite often.

I haven't checked this behavior in other editors.

Best regards,

Matjaž

PS: I'm not able to send the attachment because I get the warning that the file is too large. I can send it latter by an e-mail if you wish so.
 

[FredericL]

Hi,

As a general way of working, the 3 editors have a different way to create entities or properties.
- Aries pre-create "groups of entities and properties" corresponding ot the window shown, and shows them to you empty. If you cancel before saving, they are destroyed. If you press ok, they are just populated with the values you give.
- Cygnus presents to you for one individual all the properties related to it as memory values. If you cancel, nothing is done. If you save, all the properties that are filled in are created.
- In the Gedcom editor, it is like Cygnus but one property at a time.

In all editors, UNDO will restore the Gedcom file in memory as it was before the last OK was pressed.

So in Aries, if you add a source, a new entity is created. If you then edit the source, well, it is populated. If you cancel the editing, as it has already been created, then the empty value remains I guess. To be certain of what I am saying, please show me the screens you use and the sequence, just for these 3 steps (add, edit, cancel) and what the result is for you.

Regards,
Frederic

[Matjaz]

I understand the principle of operation of the Aries editor that you described. I did some more tests by editing the source. I managed to get two different results with the same procedure:
- canceling destroys all editing, i.e. no trace left (in my tests I didn't input any values or may be just ticked an event in Regitered Events)); this happened more often,
- canceling leaves empty values plus entry for source in the Entities table.

I see this as an inconsistency.

Please, find in the attachment my sequence together with the screens. I made the sequence only for Source and not also for Gallery where the same problem occure. (It seems my file is too big so I'll try to send it to the support team.)

Best regards,

Matjaz

[Matjaz]

I'm sending another one of my attempts to reproduce the behavior described in the previous post.

I did this in Source:

1. Opened Source Tab2.
2. Clicked Add source, then OK.
3. Opened Note Tab
4. Clicked Add a Note, then input, then OK
5. Went back to Source Tab
6. Clicked Add source for a new source, then OK
7. Clicked Cancel
Result: The source is not destroyed (entry with empty values + source entity created)

Then I continued:

8. Clicked Add source again, then OK
9. Clicked Cancel
Result: Same as above

Then I did similarly in Gallery:

1. Opened Note Tab
2. Clicked Add a Note, then input, then OK
3. Opened Gallery Tab
4. Clicked Add a new multimedia Object, then OK
5. Clicked Cancel
Result: entry with empty values + multimedia entity created

[FredericL]

OK, thanks. I'll get back to you later today.

[FredericL]

OK I can see there is a problem in the number of previous actions to cancel. Cancelling actually can sometimes cancel less actions or more actions than it should. Not sure what the best solution is.
It is limited to Aries due to the way it handles sequence of updates (users not using Aries do not get the issue). I'll come back to you when I find the fix.
Thanks for spotting this problem.

[Matjaz]

This may be an idea.

Ever since I've been using Ancestris, something about the way the OK and Cancel buttons work in the Aries editor has always bugged me. This is my suggestion on how you might improve the way they are used.

Let me first explain through examples what bothers me:

First I select the Individual Entity.

Example 1:
I create three notes in the Note tab and two notes in the Event tab. Clicking Cancel deletes only the last note that was entered in the Event tab.
- I would expect that all notes from all tabs to be deleted.

Example 2:
I entered the date of birth in the Detail tab plus four other events. Clicking Cancel deletes only the current input and the input from the previous event I added.
- I would expect all the events I added, including the date of birth, to be deleted.

Example 3
I added the event for death in the Detail tab,
then opened the Note tab, clicked Add a Note, then OK,
then opened the Source tab, clicked Add source, then OK.
Clicking Cancel deletes only the last entry for source.
- I would expect that everything I added would be deleted.

Example 4
I added several events in the Detail tab, then when I clicked on one of the events, the window Modifications in progress opened. Clicking No deletes only the current input and the input from the previous event I added.
- I would expect that all the events I added would be deleted.

Example 5
I added several events,
with the last event I also added a source, a note and finally a multimedia object in Gallery. By clicking OK in Gallery all entries added so far were confirmed, not just the one for the multimedia object (i.e. the option OK/Cancel is no longer available).
- This seems another inconsistency.

THIS IS MY SUGGESTION how to fix the above anomalies:

- The OK and Cancel buttons should be removed.
- The input of data is confirmed by clicking OK in a separate window (as for example when adding a new note, source, multimedia object etc., i.e. no change needed)
or by creating a new event or by clicking on a new tab within the same entity or on a different entity (eg. Individual, Family etc.)
One side effect of such a solution would be to align with the way how it already works in the name and related tags (i.e. Source, Notes, Other names)!
- To delete one or more entries that have been added in this way, delete button or Edit > Undo command are to be used.
- Window Modification in progress with options Yes and No would apply only to the last data being input but not saved yet.

In my opinion, such a method would be more clear and consistent from the user’s point of view.

Regards,

Matjaž

[FredericL]

Thanks for your message.
I have an idea on how to do it though. Thanks again.

Cheers,
Frederic

[FredericL]

Hi,

OK, I made a fix: (please check tomorrow)

- OK Cancel button remains. If only relates to the latest change within Aries. So, if you make a change in the source (1st change), then make a change in the note (2nd change), the note change validates the source change. Then, if you cancel, it will only cancel the 2nd change.

- The use of the Cancel button after the first change made in Aries no longer cancels a change made elsewhere by another editor before using Aries, which used to happen before this fix.

If this intented behaviour does not work, it means there is another bug somewhere. I tested a few things and it appears to be a stable and logical behaviour now.

I hope it will help.Let me know otherwise.

Best regards,
Frederic

[Matjaz]

Thank you very much for this fix. I would love to test it, but I can't because I'm using Ancestris 13.

Best regards,

Matjaž

[Zurga]

Thank you very much for this fix. I would love to test it, but I can't because I'm using Ancestris 13.

It's a good time to evolve and use the v14 

Zurga

[Matjaz]

I checked how things work in Ancestris 14. I find most of the things I've described in the examples in this post are still valid. The behavior of the Cancel command is just very unpredictable in my opinion. It is hard to explain. Would it help if I send you my log file?

I have this version of java:

openjdk version "25.0.2" 2026-01-20 LTS
OpenJDK Runtime Environment Temurin-25.0.2+10 (build 25.0.2+10-LTS)
OpenJDK 64-Bit Server VM Temurin-25.0.2+10 (build 25.0.2+10-LTS, mixed mode, sharing)

Best regards,

Matjaž

[Zurga]

The log fils will be useless.
There is no error, we don't log every actions.

Zurga

[FredericL]

Hi Matjaž,

I do not see the unpredictability on my end. The cancel action cancels the last edition. If you do, undo, do, undo, happens what you think should happen.
If you do once, twice, then undo, it only undoes the last do.

In any case, if you have a normal editing sequence, it is a normal undoing sequence.

In order to help, the log file will not show any of this. But if you identify a sequence pattern which is not working as I said above, please just provide the sequence and I will investigate.

Best regards,
Frederic

[Matjaz]

Hi Frederic,

I tested the Cancel command a bit. I am attaching some sequences where I think things are still not working as expected.

Best regards,

Matjaž