FactTypeTable.Flags

#1 · 2024-02-23, 10:37 am

Quote from thejerrybryan on 2024-02-23, 10:37 am
If I am reading the charts correctly, FactTypeTable.Flags is indicated to be unused? and to have a value of -1. Instead, it seems to contain bit switches that indicate whether or not to include the fact type in 1) Exporting GEDCOM files, 2) Publish online / create HTML, 3) Family group sheets, 4) Narrative reports, 5) Individual summaries, and 6) Printed lists.
That's straightforward enough, except that FactTypeTable.Flags often has more than 6 bits turned on. My understanding of how SQLite stores integers is a little foggy, but I don't think SQLite has the concept of things like 32 bit integers and 64 bit integers. Rather, I think that it uses only has the concept of integers, and that it uses only as many bytes as it needs based on the magnitude of the integer it needs to store.
My motivation for bringing this up is that my script for comparing my RM7 database with my RM9 database has run into a little glitch with FactTypeTable.Flags. Namely, if I create a new fact type in both RM7 and RM9 and set them up with exactly the same options, then FactTypeTable.Flags usually will not match between RM7 and RM9. The differences are not in the 6 bits that matter for my purposes. Rather, the differences are in the 6 bits that don't matter for my purposes.
I don't know if the fact that those bits may be different is a consequence of SQLite playing loosy goosy with the length of its integers, or if it is a consequence of RM7 and RM9 using those extra bits for different and unknown purposes, or if it is a consequence or RM7 or RM9 or both being sloppy and leaving those extra bits as unused bits with randomish values.
In any case, the fix in my script is to refer to those bits as FactTypeTable.Flags & 63. This works because 63 in binary is six one bits, viz., 111111. And the bitwise & operation is an AND operation which strips out the bits other than the six important bits before the comparison between RM7 and RM9.
I didn't encounter this problem initially because I was doing the comparison of RM7's FactTypeTable with RM9's FactTypeTable after importing from RM7 to RM9. The import operation copies all the bits in FactTypeTable.Flags including those that don't matter for my purposes. It was only when I recently started added new fact types in RM7 and RM9 that I ran into the extra bits being different between RM7 and RM9.
By the way, the -1 that you sometimes see in FactTypeTable.Flags simply means that all the bits are turned on, including the extra bits that don't matter for my purposes. The extra bits may or not be being turned on purposely by RM. Rather, RM may be being a little sloppy with its use of integers to store bit switches, and it is encountering sign extension that's associated with the way negative integers are stored in 2's complement notation. Positive integers are left padded with as many 0 bits as necessary and negative integers are left padded with as many 1 bits as necessary. And the left bits are sign extended when for example a 16 bit integer is stored as a 32 bit integer or as a 64 bit word.

If I am reading the charts correctly, FactTypeTable.Flags is indicated to be unused? and to have a value of -1. Instead, it seems to contain bit switches that indicate whether or not to include the fact type in 1) Exporting GEDCOM files, 2) Publish online / create HTML, 3) Family group sheets, 4) Narrative reports, 5) Individual summaries, and 6) Printed lists.

That's straightforward enough, except that FactTypeTable.Flags often has more than 6 bits turned on. My understanding of how SQLite stores integers is a little foggy, but I don't think SQLite has the concept of things like 32 bit integers and 64 bit integers. Rather, I think that it uses only has the concept of integers, and that it uses only as many bytes as it needs based on the magnitude of the integer it needs to store.

My motivation for bringing this up is that my script for comparing my RM7 database with my RM9 database has run into a little glitch with FactTypeTable.Flags. Namely, if I create a new fact type in both RM7 and RM9 and set them up with exactly the same options, then FactTypeTable.Flags usually will not match between RM7 and RM9. The differences are not in the 6 bits that matter for my purposes. Rather, the differences are in the 6 bits that don't matter for my purposes.

I don't know if the fact that those bits may be different is a consequence of SQLite playing loosy goosy with the length of its integers, or if it is a consequence of RM7 and RM9 using those extra bits for different and unknown purposes, or if it is a consequence or RM7 or RM9 or both being sloppy and leaving those extra bits as unused bits with randomish values.

In any case, the fix in my script is to refer to those bits as FactTypeTable.Flags & 63. This works because 63 in binary is six one bits, viz., 111111. And the bitwise & operation is an AND operation which strips out the bits other than the six important bits before the comparison between RM7 and RM9.

I didn't encounter this problem initially because I was doing the comparison of RM7's FactTypeTable with RM9's FactTypeTable after importing from RM7 to RM9. The import operation copies all the bits in FactTypeTable.Flags including those that don't matter for my purposes. It was only when I recently started added new fact types in RM7 and RM9 that I ran into the extra bits being different between RM7 and RM9.

By the way, the -1 that you sometimes see in FactTypeTable.Flags simply means that all the bits are turned on, including the extra bits that don't matter for my purposes. The extra bits may or not be being turned on purposely by RM. Rather, RM may be being a little sloppy with its use of integers to store bit switches, and it is encountering sign extension that's associated with the way negative integers are stored in 2's complement notation. Positive integers are left padded with as many 0 bits as necessary and negative integers are left padded with as many 1 bits as necessary. And the left bits are sign extended when for example a 16 bit integer is stored as a 32 bit integer or as a 64 bit word.

#2 · 2024-02-23, 11:44 am

Do these flags also save "field usage" for facts? i e. which fields are displayed in the ui- date., place, desc. etc.

#3 · 2024-02-23, 12:53 pm

No, those are controlled by the fields UseDate, UseValue, UsePlace in the FactTypeTable. Until Jerry posted that there might be some difference between RM7 and RM9's use of the Flags field, my understanding was that it was solely related to what outputs are set for the given fact type. See Fact Inclusion Controls.

#4 · 2024-02-23, 1:58 pm

"Until Jerry posted that there might be some difference between RM7 and RM9's use of the Flags field, my understanding was that it was solely related to what outputs are set for the given fact type."

I still suspect that's true. The bits probably only control the actions you can see when you are editing a fact type in the RM user interface. It's just that there additional bits in the FactTypeTable.Flags field that we don't see in the RM user interface. If they are meaningful, then they must mean something different between RM7 and RM9. I suspect that the additional bits are not meaningful and that they are being left undefined - sometimes 0 and sometimes 1. Then I suspect the seventh bit from the right is becoming sign extended. But we don't know that for sure. The bits might well be meaningful. But I doubt it because RM9's import from RM7 simply copies the bits as as.