| Name | Description |
|---|---|
| GroupHookup | A GroupHookup subclass is used for any hookup that can be a parent of other hookups. For example, a SequenceHookup has a child hookup for each item in the sequence; an ItemHookup has children which are the hookups for the various properties displayed. It keeps track of its children in order. It also knows a containing box in which its parts are placed. |
| Hookup | A Hookup represents the connection between the domain (a property of an object) and a section of a view (one or more boxes or strings). Typically it knows how to connect to an event (and disconnect when disposed) that is raised when a particular property changes, how to get the value, and how to inform the view of the change. Some subtypes may (eventually) know how to perform the reverse operation, that is, when something in the view is edited, the Hookup knows what should be changed in the domain model. |
| HookupAdapter | This class (more specifically, its subclasses) adapt from one particular property of some class to what some kind of Hookup needs to monitor it. |
| ItemHookup | An ItemHookup groups together the hookups for the various properties of an individual object, typically an item in an IndependentSequenceHookup. It may also track one or more boxes which belong entirely to this item. For example, a LexEntry might have one paragraph which holds most of its content (the text part), and another which holds its pictures. The ItemHookup would track the two paragraphs as well as the hookups which hold the various properties of the LexEntry. If the senses of the entry are displayed as a sequence of strings within the one paragraph, the ItemHookups for the senses would not track any box, just the individual string hookups (or possibly another layer of IndependentSequenceHookup holding example sentences, etc.). |
| LiteralStringParaHookup | This is a cut-down version of StringHookup used in selection of client runs that don't have natural hookups, such as literal strings. It never sends change notifcations, so doesn't need delegates for updates and notifications. If you find a LiteralStringParaHookup where you expected one that allows editing, like StringHookup or TssHookup, one possible cause is that you don't have a correctly named "XChanged" event being triggered when your property X changes. |
| MlsChangedEventArgs | Indicates that a particlar alternative of a multilingual property changed. This will have to move to FDO along with IViewMultiString. |
| MlsHookup | This class manages the hookup between one alternative of a multilingual string property and the place where it is displayed. |
| MlsHookupAdapter | |
| MultiplePropChangedReceiver | This class handles the unusual case where we want multiple hookups receiving PropChanged for the same Hvo, tag pair. It replaces the first two and can have more added. |
| ObjectSequenceEventArgs | This class is used to implement events which indicate that an object sequence has changed, and explicitly provide SharpViews with information about which objects in the sequence changed. This may be done either to improve performance, or so that the client can force the display to update for a particular sequence of objects even though the sequence may NOT actually have changed. The arguments indicate the first object in the value when the display was last updated that has been deleted, or (if numberDeleted is zero) the one before which objects have been added. The other two arguments indicate how many objects in the current display have been removed and how many (in the current value of the property) are considered new. |
| RootHookup | This hookup serves as the connector for everything in a root box. There is no target object. |
| StringHookup | |
| TssHookup | |
| TssHookupAdapter | The information a TssHookup needs in order to hook to a particular string property of a particular object. This is intended to support one style of view construction with SharpViews. The idea is that, given a class like StTxtPara and a property like Contents, we could generate a helper class StTxtParaProps, with static methods like this: class StTxtParaProps { public static TssHookupAdapter Contents(StTxtPara target) { return new TssHookupAdapter(target, () => target.Contents, hookup => target.Contents += hookup.TssPropChanged, hookup => target.Contents -= hookup.TssPropChanged); } } This then allows us to do something (as yet not fully designed or implemented) like aView.Add(StTxtParaProps.Contents(aPara)); Problems: (1) the above doesn't look particularly fluent; (2) we have a dependency problem between SharpViews (which defines TssHookupAdapter) and FDO (where we'd like to keep the model-specific code generation). SharpViews already references FDO, and it's unlikely we can change that. The approach used in ExpressionDemo may be more promising. |