C# (CSharp) SIL.FieldWorks.FixData Namespace

Classes

Name Description
BasicCustomPropertyFixer This fixer is responsible to ensure that all custom properties that have value (or basic) types have an actual value in the file. Although FLEx ensures this when writing the file, a merge could potentially merge a new custom field definition from one user with a new instance that was created without the custom field from the other user.
CustomListNameFixer This class handles custom lists with duplicate names.
CustomPropertyFixer If two users are doing Send/Receive and one deletes a Custom Field (or Custom List!) and the other edits the same custom property, Chorus will keep the edit, but we have no way to recreate the custom field, so delete the (now) undefined custom property.
DuplicateStyleFixer This class ensures that we don't have two StStyles with the same name in the same owning list. This is crucial since FLEx will fail to start if it happens. If it does happen, we arbitrarily remove all but the first one with a given name and owner. This fix must be run before removing dangling references, since it may create dangling refs, if some other style specifies a deleted one as its Next or Base. Return false if we need to delete this root element.
ErrorFixer Connect the error fixing code to the FieldWorks UtilityDlg facility.
FwDataFixer Fix errors in a FieldWorks data XML file.
FwDataFixer.OriginalFixer This class contains the adapted code for the original FwDataFixer which tried to handle a small set of reference and writing system problems. It attempts to repair dangling links, duplicate writing systems, and incorrectly formatted dates It also identifies items with duplicate guids, but does not attempt to repair them.
GrammaticalSenseFixer Fix up any entries that are found to contain MSA references which none of the senses have. Those references are simply removed.
HomographFixer For projects using Send/Receive, two users on separate machines can create Lexical entries which have the same form and MorphType. When merging is done these items will have different GUIDs and their Homograph numbers will both be set to zero '0'. If these were created on the same machine they would show as having Homograph numbers 1 and 2. This RtFixer is designed to correct this problem. In the above example the Homograph numbers should end up being 1 and 2.
MorphBundleFixer This fixer handles cases where a WfiMorphBundle has a dangling MSA pointer. - if it has a sense that has an MSA, the MSA is fixed to point to it. - if it has a morph that belongs to a valid entry that has only one MSA, the MSA is fixed to point to it. Also, if it has a dangling Morph pointer, - if it has a sense that belongs to an entry with only a LexemeForm and no allomorphs, the Morph is fixed to point to that Lexeme form. If a good fix cannot be made the dangling objsur should be removed. (The usual removal in OriginalFixer has been suppressed to let this one try for a better fix first). Also correctly fixes an MSA pointer that is not originally dangling, but will become so because the MSA will be deleted for lack of any referring senses.
RtFixer This abstract class provides the interface for fixing problems on an element\row\CmObject level. The members m_guids and m_owners can be used by fixes which need global information.
SequenceFixer This class contains code to fix situations where merges have resulted in sequences that are empty and shouldn't be. In normal operation, FDO takes care of these situations automatically, but in a Send/Receive situation FDO might not 'know' that one user deleted a sequence element while another user deleted the other with the result on merging that now both are gone. Usually the required fix is to delete the parent that holds the sequence. This class also contains code to fix situations where merges have resulted in a Segment being deleted and dangling references still exist in TextTag objects and ConstChartWordGroup objects. In normal operation, FDO takes care of these situations automatically, but in a Send/Receive situation FDO might not 'know' that one user deleted a Segment element while another user created references to it, with the result on merging that now references to a non-existent Segment exist. The Original Fixer will delete the dangling references to the Segment, but the TextTag and WordGroup objects should not have empty Begin or EndSegment references. If both Begin and EndSegment belong to missing Segments, we delete the object in question. If only one belongs to a missing Segment, we replace its reference with a reference to the other Segment. This class also contains code to fix situations where a LexReference object is found to only contain one Target. The LexReference object will be deleted. There may have been bugs in the past which allowed this sort of thing to occur. They seem to have been fixed, but Send/Receive could conceivably generate such situations too.
Strings