Messages

1

ENGLISH / Re: Canceling input for Source not working as expected

« on: April 15, 2026, 16:56:16 »

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ž

2

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 10, 2026, 08:33:51 »

Thank you very much for your clarification. At least now I know that I put my data in seemingly the right place and that the problem wouldn't have occurred if I had used some other editor instead of Aries. Thanks also for your offer to make corrections to my file, but I think I'll be able to do it myself.

Finally, I would like to ask what you think about my proposal to add the possibility of retrospective categorization and, if necessary, recategorization of occupations in Ancestris. I think this would be a useful tool. (Or maybe there's already a way to do it and I just don't know.)

Best regards,

Matjaž

3

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 09, 2026, 14:11:34 »

I understand what you're trying to tell me. However, I still can't accept that my understanding of where to enter which data in the case of "Event" is wrong. Let me emphasize that for editing I only used Aries, and not Gedcom.

The following is a description of my reasoning:

The tooltip for "Event Descriptor" in Aries (Ancestry 13) gives the following explanation: "A descriptive word or phrase used to define the event being cited". The explanation in the tooltip for event property "TYPE" in Gedcom gives similar explanation: "Type: a descriptive word or phrase used to further classify the inormation". So "Event Descriptor" in Aries should correspond to "TYPE" in Gedcom. It was my understanding that I should only use a short term here, which I did (eg. Military operations). I did similarly in the case of event "Occupation", and yet the data representation in Gedcom is not the same as in the case of event "Event": correct in the case of "Occupation", incorrect – in my opinion – in the case of "Event".

I’m very sorry but I’m still not able to understand why I would have to enter the data for type in Aries in the case of "Event" in the exact opposite way as in the case of "Occupation" to get it right in Gedcom.

Best regards,

Matjaž

4

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 09, 2026, 08:15:39 »

What you explained about the Gedcom editor is true. The data from the Gedcom editor did carry over from Ancestris 13 to Ancestris 14 as is. But the problem already arose in Ancestris 13, because the data for "Event" entered in the Aries editor was entered into the wrong properties in Gedcom. Plese, see the attachment with an example for the event "Event", which I write about all the time (in other events such as "Birth" etc. I did not detect any irregularities).

As a result, this error would need to be fixed in all the instances for "Event", and they are rather many in my database.

Best regards,

Matjaž

5

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 08, 2026, 22:37:09 »

Yes, for newly created individuals this seems understandable to me! And that's how it actually works now. But I'm not happy that all the events that I've added in the past in the Aries editor as "Event" were changed to "Event type" (the same has also happened in the Gedcom editor). For example, the event "During World War I, he fought on the Isonzo front" became "Event type", and the description "Military battle" in "Event descriptor" became "Event". If things worked the way they do in the case of occupations, where "Occupation" equals event and "Event descriptor" equals "TYPE", I would understand, but now the whole thing seems to me even more confusing. I hope this can be cleared up. Please, excuse me for being so persitent.

Best regards,

Matjaž

6

ENGLISH / Re: Canceling input for Source not working as expected

« on: April 08, 2026, 16:56:28 »

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ž

7

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 08, 2026, 15:20:34 »

I just checked in Ancestris 14 for the problem I described in my previous reply. I see that the problem has also been transferred to Ancestris 14. If I illustrate it only with the example of the Aries editor, which I mainly use, the data from "Event" from Aries (Ancestris 13) was transferred to "Event type" in Aries (Ancestris 14), and the data from "Event discriptor" from Aries (Ancestris 13) to "Event" in Aries (Ancestris 14), which I think is not correct. Both data types are now swapped and no longer appear logical.

This is most likely due to the fact that already in Ancestris 13, data entered in the Aries editor was transferred in this way to the Gedcom. There is no such problem with "Occupation" and "Event type".

Best regards,

Matjaž

8

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 07, 2026, 18:53:11 »

Thanks, I'll take a look.

I am submitting another observation regarding the "type" property.

I did a quick comparison of the Aries and Gedcom editors for the "type" property:

"Occupation" in Aries is "OCCU" in Gedcom, "Event Descriptor" is "TYPE" in Gedcom, which should match your explanation.

But "Event" in Aries becomes "TYPE" in Gedcom and "Event Descriptor" in Aries becomes "EVENT" in Gedcom, which is rather the opposite of occupation. Is that right, or is it an inconsistency? I find it confusing.

Matjaž

9

ENGLISH / Re: Proposal to add "Type" property in Aries editor

« on: April 07, 2026, 17:16:22 »

Thanks for your explanation.

I can see that TYPE from Gedcom is added as Event Descriptor in Aries 13.

As for the rest, it seems there is no easy way to retroactively categorize occupations that have been assiged so far. But may be that this functionality already exists in Ancestris 14 and is just waiting for me to try it out!?

Best regards,

Matjaž

10

ENGLISH / Proposal to add "Type" property in Aries editor

« on: April 06, 2026, 11:58:11 »

The Type property only exists in the Cygnus editor, but not in the Aries editor, although it would be useful. Wouldn't it make sense to have this option in Aries as well? After all, Aries is supposed to be more complete than Cygnus.

It wasn't until I read one of the previous posts on the topic of "type" that I realized that I could have used the type property before, at least in connection with occupations. But since I mostly use Aries, I didn't even think about it, even though I could have done it in the Gedcom editor.

During all this time, I have accumulated a long list of occupations that I would now like to categorize. I see no other option than to do it one by one. I imagine that it would be easier to do this if there was a similar list for types/occupations as there is for places (List/Table of palce), with the option to edit, replace, etc. Such a possibility would also be interesting to have in the long term, since there is always a need to change the names of occupations and re-categorize them.

Best regards,

Matjaž

11

ENGLISH / Re: Canceling input for Source not working as expected

« on: April 03, 2026, 13:42:53 »

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ž

12

ENGLISH / Re: Canceling input for Source not working as expected

« on: April 01, 2026, 12:51:00 »

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ž

13

ENGLISH / Re: Canceling input for Source not working as expected

« on: March 31, 2026, 09:39:32 »

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

14

ENGLISH / Re: Canceling input for Source not working as expected

« on: March 30, 2026, 22:54:47 »

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

15

ENGLISH / Canceling input for Source not working as expected

« on: March 29, 2026, 18:21:30 »

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.