The English section of the forum has no dedicated thread/location to report bugs (yes, they do come up!), as does the German section. I am starting this thread in the hopes that it will be "pinned" as a place for people to report bugs. My intention is to maintain a single list (following) for the author (or anyone else) to view, categorizing bugs for easy analysis. Since only I can modify this post, others reporting bugs should just post to this thread as replies; I will verify and add to the list as needed. Ahnenblatt is quite thoroughly de-bugged so I don't expect to be swamped. Most of the bugs I have found are because of my testing, etc. in preparation for the English help file (hoping for a Beta version before the end of this month).
The list has bugs numbered (just for convenience), and some use of colors may be helpful. As bugs are fixed (and I hope they will be!), I will either remove them, recolour them (greyed out), or ? (to be decided).
Bugs 1..5 have actually already been reported, but in other threads (or email, in one case). I will re-state them here, just for convenience. Some items (in the Oversights thread) could be posted here, but are not really detrimental to Ahnenblatt's performance; they don't really qualify as bugs.
Ahnenblatt v2.85
- FILE SEARCH (12/08/2014) File/Search not working properly
Search is not searching subfolders of NTFS drives, or flash drives (by design?). Scan time is far too short, based on other applications which search drives. Ancestry files appear to be found in subfolders of FAT16 drives. Finding of files on NTFS drives is incomplete. (modified Jan 30/15) - DATES (12/14/2014) Date range - between DATE1 and DATE2 broken since v2.83
Substitute words (BET -> between, AND -> and) do not work. Changing, i.e. GEDCOM.BET=BET\~bet works, but only for years, not month&year or day&month&year. Creating a date using "bet" in a .GED file, then writing it out as a .ged file (i.e. Save as...) reveals that the GEDCOM modifier is now written as "bet", not "BET". Seems to work fine in v2.83. This tells me that I think the wires between the hardwired string "BET" and the language variable string "bet" have become crossed. I did a memory snoop (using HxD hex editor) - the GEDCOM.BET variable IS getting loaded. (modified Jan 30/15) - DATES (12/14/2014) Date period expression "from DATE1 to DATE2" not working (see #2)
Similar behaviour to bug #1, re: substitute words. Seems to work fine in v2.83. - DATES (12/14/2014) Interpreted dates (INT) not parsing correctly
INT JUL 1898 (summer of '98) parses as interpreted 18/07/0008 (summer of '98) without any error, re: GEDCOM compatibility. - PERSON SEARCH (01/02/2015) Search option "Identical with whole data field" appears to do nothing
Marcus hat geschrieben:
"Identical with whole data field" looks to be broken ... when searching for "Regina Hertha" in the field "First/Birth Names" in the file "Beispiel.ahn" it shouldn't find "Willner, Regina Hertha Klara" since the fields don't match exactly. It looks like the results are just the same as with the 'base option' without recognizing the check-box "Identical with whole data field".This item now reposted in Oversights thread (009) - this might not be a real bug (deprecated feature?).Fixed in v2.88 - DELETE GROUP (01/04/2015) Delete group Ancestor/Descendant list (before delete) has 1 extra person
When using the 2 Ancestor modes, and the 2 Descendant modes (Selection), the targeted person is always included in the deletion list, ie. he is his own ancestor, and his own descendant. I think he should be excluded from the list. Using Except selection does not show the targeted person on the deletion list (correct for the situation, but wrong due to bug).By design (per Marcus/Dirk) - DELETE GROUP (01/04/2015) Delete group routine for "living persons" is flawed
Choosing "living persons" appears to include the same persons for Selection and Except selection; the lists appear identical.Fixed in v2.88 - MOUSE HANDLING (01/05/2015) Using mouse wheel to scroll causes an error message
Attempting to scroll the mouse down (no error on up!) in the Details tab of a Statistics dialog causes the following application error:
"Gitterindex außerhalb des zulässigen Bereichs" (English: "Grid index out of range")
To replicate the error, do the following (tested on Win XP SP3):- Open Ahnenblatt and use "Demo.ahn". Error seems related to unitialized variable or focus related (?), not always repeatable unless opened "fresh".
- Use Tools/Statistics/First_name to open the Statistics dialog
- Activate the Details tab (66 entries)
- Drag the slider to the bottom of the list (viewing 66 Willi)
- Scroll the cursor (using mouse wheel) down - error produced
4a. Click anywhere on the control (grid) to give it focus (?) - NAVIGATOR (01/05/2015) Surname prefix shown incorrectly in Navigator
If a surname prefix is entered in the Name tab of the Input dialog, e.g. Birth name = "Fleur", surname prefix = "de", the top-right corner display (Input dialog), the data box (Navigator), the tooltip for the person (Navigator) and other places all show the last name as "de Fleur". The person box in the Navigator, however, shows an additional comma and in reverse order - "Fleur, de". I believe it should show the same as the other locations (e.g. "de Fleur, Marcel").Fixed in v2.88
Note: all locations (except Navigator person box) show the same last name, whether the name is entered as Birth name = "de Fleur" or as shown above (Birth name with prefix). - Ahnenblatt v2.86
DELETE GROUP (01/05/2015) Choice 3 - "(Ancestor (complete) of..." using wrong groupbox language variable in "All persons" selection dialog
Clicking Next after selecting this method of group deletion opens a person selection dialog. The text for the groupbox is "Selected person (last name, first name)", but should be "Proband/youngest person (last name, first name)", to match choice 2. This indicates that - in the language file - [$CONSTANTS]/StartPerson is being used instead of [$CONSTANTS]/YoungestPerson.Fixed in v2.88
This is a minor cosmetic bug, but does affect translations, etc. - Ahnenblatt v2.87
FILE/SAVE_AS (01/05/2015) Save as... function on File menu - save file as RTF (a.k.a. Windows help file) - is broken
When saving a file as a "Windows help file" (that is, RichText Format - modified), only a single person is saved. This renders that function useless. The file can be read (i.e. valid RTF), but is incomplete. This function worked in v2.85, but apparently was broken in v2.86 (and v2.87).Fixed in v2.88